Random ideas for tweakmodes and other such stuff.

[FavoritoHJS]

CGA

• For the 80x100 tweakmode, change the character to the 25% dither to up the color count to 256
• If you find an unicorn CGA that is not a snail at writing, you could also modify the character for even more colors (I imagine 400 on RGB should be possible in real time)
• Also, might be worth looking in whether CGA supports Intelaced mode, how it does (or doesn't) and how common it is, as I suspect setting up Interlaced mode incorrectly might just be the key to low-maintenance 1k on composite.

Hercules

• Use a similar technique as talked on the EGA (just instead of rendering a taller viewport, also a wider one) to allow for true 720x350 for monitors that don't support the 640x400 tweakmode.
• There are some Hercules cards (See: Hercules Plus) that can select arbitrary charsets, which means MOAR TWEAKMODES
  • Totally not a framebuffer: Use 16-tall characters, set the screen to a pattern of them and modify the characters themselves to get a (sorta-kinda) linear framebuffer, with free strikethrough/underline and extra greenshades!
  • Yet another tweakmode: Use 3-tall characters (not official but I'm fairly certain it can be done) to get an (80/90)x116 viewport. This only occupies 21k of the cards 64k, meaning it can be done in half-mode (as it doesn't use all of the 32k that has mapped), and you can have 2791 (or 743 on half mode) characters free for remapping.
    • I'm sure you could get a true framebuffer using 1-tall characters and mid-frame CRTC shenanigans but (a) horizontal color bleed would make it not very useful and (b) that would be painful, please don't.
    • Remember that, as you will be using the 48k RAMFont mode, you can still use strikethrough, underline
      and reverse to help with drawing.
    • Due to the slow speed of the ISA bus, I'm not sure if this would be very practical, but that idea could serve as the base for some funky low-res tweakmodes.

EGA

• For the 160x100 mode, render 160x116 instead, allocating those extra scanlines to a taller viewport.
• Ways to get an 80x116 tweakmode:
  • Modify the character to a 33% dither, change just the attribute byte, instant 256 colors.
  • If you can use a different pallete for the background and foreground, you can do so and, if you share no or just one color, achieve 256 colors with a finer dither!
• Characters are on plane 0, attributes on plane 1, charsets on plane 2. If you only need to modify one of these, disable the other planes and REP MOVSW away!
• Potential planar speedups:
  • Write 8 pixels of the same color using Write Mode 2
  • Write 8 pixels of 2 colors using Write Mode 0 and latch abuse.
    • Should this not be feasible, you might be able to use a bit mask, but that would sap much of the advantage if you have to reset it frequently.
  • Write 8 pixels of 3 colors by first laying down a "foundation" as before, then printing over with a single-color "overlay" using Write Mode 3.
  • Anything over is probably better served with per-plane copying.
  • If 2 or more planes are identical, they can be written using a single write to both of them. This is probably more useful with 256 colors, but you might be able to find a pallete that can still take decent advantage of this.
• Scrapped ideas:
  • Transfer the image per-color instead of per-plane to cut down on the memory accesses, assuming plane switching and latch loading won't take too long.
    • Copying per-plane requires 4 accesses a byte, so that's the benchmark.
    • Copying per-color requires 2 accesses per color -- one to load the latches, the other to write.
    • This means the crossover is at 2 colors a byte, the same point that latching shenanigans can do a write in a single access (plus IO, though if that isn't horrendusly slow I don't think it would make much difference).
    • Even if this worked, the overlay method is more general (works up to 4 colors) so it's worth using.
• Do note that palletes can be set quickly, so damage/pickup flashing shouldn't be TOO hard to get working. (though the low color depth means they won't work well).

VGA

• 160x200@256 mode by using whatever the EGA's 320x200@16 mode uses (Dot Clock Rate?) to double horizontal pixels.
  • This mode would have a small enough buffer (32k) to allow for double buffering without dealing with planes.
  • If you want to deal with planes anyways, you can fill up to 1/40th of a line with a single byte transfer, potentially allowing for really fast floor/ceiling fills.
  • Can you stack clock dividers? If so, you could achive further chunkyness by using the 2x and 4x memory access dividers (especially if they stack!). Turn your IBM into a VCS today!
• Implementing the EGAs planar speedups would work on 256-color mode as well, though it will be quite hard.
  • I suggest implementing it in 16 colors first (to ensure the code works) and then port it to 256 planar.
  • 2 colors per block would work just like on 16 color planar (if you don't believe me, draw out the bit patterns) Wrong, see comment
  • 3 colors, on the other hand, looks to be intermittent, and very dependant on how the pallettes line up. Might be worth looking into optimizing the pallete to maximize how often 3 256-color blocks can be mapped to 3 unique plane setups.
• Text tweak-modes might be quite useful to:
  • Achieve line tripling and beyond
  • "Compress" the image using carefully selected palletes and charsets to reduce frame size, and thus, bandwith usage.

General considerations

• A key problem with oldskool graphics will be getting the required bandwidth as low as possible, as they are usually connected with the (slow) ISA bus, usually 8-bit, and with about 30 billion waitstates to boot.
  • This means that simpler, "worse" modes might just be better due to less bandwidth required to run them.
• A general technique for these weird color modes: Instead of transforming the entire video port over, do a native render on the appopriate color depth.
  • So, instead of rendering 16 colors first as 256 and then quantizing, render it as 16 colors from the start.
    • This would be much more complex, but would allow for proper dithering, color mapping, the works.
    • Making each render adapter-specific could also mean that, instead of using a linear framebuffer render and then transforming it to planar, it's planar all the way through.
      • Could also help by not writing so much to main memory if that data will only be used for the framebuffer anyways.
• Having SO many executables isn't that great, might be worthwhile to do some runtime-loading dynamic linking of the correct renderer.

[viti95]

Pretty interesting ideas, will see what of them can be done. For now these are the things and thoughts that I've learned while working on these modes:

• As you say, 8-bit ISA cards are slow as hell. It's better to process everything on RAM, and then decide what is required to be copied to the VRAM. This gives huge speedups on 8-bit cards, not so much on 16-bit cards. Most 8-bit ISA CGA and EGA cards are limited to ~500kb/s writes, while faster ones do about ~900kb/s.
• On EGA/VGA cards I wasn't able to write directly to plane 0 on text modes (some characters were modified also), and haven't found any example or way to do this without issues.
• Write Mode 2 on EGA/VGA cards wasn't as fast as I expected to do chunky2planar conversion per pixel, that's why I process every color plane on it's own.
• I haven't used the whole EGA screen on text modes since those doesn't have the same pixel ratio as Doom, and I really hate the distorsion when aspect ratios don't match. Same for the Hercules 720x350 mode.
• I'm still looking for EGA optimizations, I do really hate the chunky2planar conversion process. Plantronics ColorPlus is much faster compared to EGA because of this. The main issue with EGA for me is that there aren't much examples on how to optimize properly for it.

[FavoritoHJS]

On EGA/VGA cards I wasn't able to write directly to plane 0 on text modes (some characters were modified also), and haven't found any example or way to do this without issues.

After doing some reading, I imagine odd/even mode (what's used to weave both bitmaps) is causing shenanigans there, writing to both plane 0 and plane 2 when you only want to write to plane 0. Does disabling it destroy the dispaly?

I haven't used the whole EGA screen on text modes since those doesn't have the same pixel ratio as Doom, and I really hate the distorsion when aspect ratios don't match. Same for the Hercules 720x350 mode.

Stretch the playfield then! No-one said a pixel in any given mode had to match some pixels in another.

I'm still looking for EGA optimizations, I do really hate the chunky2planar conversion process. Plantronics ColorPlus is much faster compared to EGA because of this. The main issue with EGA for me is that there aren't much examples on how to optimize properly for it.

I imagine many resources for the VGA's planar modes (whether that be 16 colors or Mode X, though the former would be more useful for this case) should also be applicable to the EGA, unless it uses something that the EGA doesn't have, but the VGA does.

From what I recall, a general rule of thumb is to access the card as little as possible to draw any given frame.

Also, I was wrong with the "256 color drawing like 16 colors" thing. That would give up to 4 possible bitplanes: All 0's (both original colors have a 0 in that plane), all 1's (both original colors have a 1), any one bit pattern (defined by where the colors are placed) and its bit complement.

You can still use the "flood and mask plane-wise" method though.

[viti95]

I'll use the idea "Write 8 pixels of the same color using Write Mode 2" for a new optimized EGA mode. Based on the mode 640x200, if we use 8 pixel writes we get a base 80x200 resolution.

It has multiple benefits:

• Avoids CPU heavy chunk2planar conversion
• Avoids having to write on multiple planes
• Only 16.000 bytes written per frame (maximum, if we use differential copies it lowers), using a slow 8-bit ISA card (~500kb/s) we get more than ~32 fps

[FavoritoHJS]

Already posted this in a youtube comment, but since I want to flesh this out further, I'm posting here as well.

Small note on memory locations: I will refer to them as offsets from the CPU's side, and not from the VGA's side, so when I say F000, for example, that means F000 bytes from the start of the CPU's window to VRAM, and not from the start of a theoretical linear VRAM.

A theoretical way to get 320x200@24:

• Setup
  • Set up a lookup table of 4k in size, such that:
    • Plane 0 is zero'd so it won't conflict with logic,
    • Plane 1 has doubled-up versions of bits 11~8,
    • Plane 2 is the same, but using bits 7~4, and
    • Plane 3 uses bits 3~0.
    • By "doubled-up", I mean that, for example, bit pattern 0010 turns into 00 00 11 00.
  • Configure the VGA as such:
    • Set/Reset to leave Plane 0 as-is, and fill Planes 1-3 with 0s.
      • This, combined with the Logical Operation, gives control of all planes.
    • Logical Operation set to OR data with latches.
      • This combines the latch data with the CPU's.
    • Leave the bit mask blank!
      • If a bit mask bit is set, that bit is always filled with data from the latches, which means you can't use the CPU's written data to control it!
• Rendering
  • Read a byte from the lookup table to set the latches (and thus, planes 1 through 3) correctly (if they aren't already)
  • Write a byte into memory, with the written value being what would go into plane 0.
    • You could write a word (or more!) if you don't have to change the latches again, though I don't think that would help a lot.

Also, about the limits of this technique:

Since this uses a base mode of 640x200, and we'll want double buffering (I don't think your run-of-the-mill EGA will be able to race the beam well enough), that will use 32k of address space, leaving another 32k free.
This means a single CPU read can transfer up to log2(32k) = 15 bits of information to the latches.
Of course, that data needs to be written somewhere, so a CPU write is required. 8 more bits of information can also be obtained.
Thus, for every 2 VRAM accesses, up to 23 bits of information can be transfered. Now about how to best use that without requiring further VRAM -- or worse, IO accesses...

PS: From what I recall, 200-line modes do NOT support all 64 colors of the EGA, as the monitor is running in CGA compatibility mode.
However, you can still set up a pallete, so the color in VRAM is different to the color outputed to the display.
I'm mentioning this (again...) because, aside from the obvious use of low-cost flashing, should the code have been faster if only some colors were using some specific bit relations, you can set those bit relations yourself and get your speed that way.

[FavoritoHJS]

It's time for even more crazy mumblings!

CGA

First, I imagine if you have a Tandy-style graphics adapter, you might be able to display 256 colors in that using composite artifacting and the 640x200@4 graphics mode

• 640x200 is chosen specifically since it makes correcting for the varying colorsync phases on each bootup easy, just shift things over some pixels.
  You can't quite do that in 320x200, though, so unless you can somehow reset the colorphase in software, your results will change on every boot, so you'll need 4 whole converters!
• The practicality of implementing this is very low, as, to the best of my knowledge, no computers have Tandy-compatible graphics AND a 386, so this could only be used in some funky hot-rodded 1000TX or something.

EGA/VGA

Progress on my idea of transfering 3 planes with 2 card accesses

• For reference, here's the pipeline for Mode 0 writing
  • Barrel-rotate the CPU data.
  • For each plane, determine if to use previous data or Set/Reset data
  • Perform bitwise OR, AND, XOR between the previous data and latches, or just pass the previous data
  • For every bit in a plane, select between the prevous data and latches.
    • Every plane has the same bit mask!
  • Write to write-enabled planes.
• You can do bitwise NOT in a plane by:
  • Setting the ALU to XOR
  • Using Set/Reset to ignore CPU data for a plane, and replace it with all 0's, or all 1's.
  • Since the effect of XORing a value with all 1's is its bitwise NOT, that means we've just flipped a plane's bits.
• This is important, as it means 1 extra bit of easily-controlled data per plane.
  • This means that this could be a faster way to fill a screen!
    • Use a 16k-address-space-sized (64k of VRAM, so it can fit in a 128k EGA!) look-up-table as such:
      • Plane 0 is don't care
      • Plane 1 is all 0s (so the ALU doesn't change the value)
        • Note: It doesn't need to be all 0s, so long as you know the value beforehand... but why would you overcomplicate things for no reason
      • Plane 2 contains 7 bits of address space
      • Plane 3 contains another 7 bits of address space.
      • Thus, when a value here is read, 7 bits of planes 2 and 3 can be controlled without affecting each other.
    • Then, pass over the screen 4 times as such:
      • First, fill all bytes that would have bit 7 of planes 2 and 3 not set
      • Then, do it again, but with bit 7 of plane 2 set and 3 not set, and doing a plane-wise NOT on plane 2.
      • Then again, with planes 2 not set, and 3 set, with a plane-wise NOT on plane 3.
      • And finally, with planes 2 and 3 set, with a plane-wise NOT on both planes..
      • During this proccess, you will have to correct for 0's in a plane becoming 1's.
    • If everything has gone correctly, this is what the plane layout should look like:

      +--------+
      |DONTCARE| Plane 0
      |CPU DATA| Plane 1
      |LATCHED | Plane 2 
      | DATA   | Plane 3 
      +--------+
      

    • Lastly, do a normal single-plane blit on Plane 0.
    • This is a very experimental process, I imagine you could set the values and palletes up so for most screen bytes, you won't need things like the extra "set plane 0" pass most of the time.
      • Hell, if optimized correctly, this might provide a small ammount of lossy compression (doing 8 passes with 3 planes being set from latches would give 15+3=18 bits for them, probably enough for 320x200+mild dither), perfect to work around ISA bandwidth issues.

Also, potential overscan modes with CRTC tweaking?

• 640x200 -> 720x240 (EGA with CGA monitor)
• 640x350 -> ??? (EGA with EGA monitor, I don't know exact timings so I can't tell you the maximum timings.)
• 720x400 -> 760x410 (VGA at 70Hz, could push to 800x420, divide hres by 2 for 256-color modes)
• 720x480 -> 760x496 (VGA at 60Hz, could push to 800x512, divide hres by 2 for 256-color modes)
  Though because you'll have to actually render that much data, and the renderer seems hard-coded to 320x200 (else what would prevent you from making actual 350px modes), I doubt the practicality of these.

[FavoritoHJS]

Bonus idea: I wonder if you can fake a slightly higher precision EGA pallete by switching palletes every (displayed, not engine) frame...
By mixing this with double-buffering, that might also be a pseudo-256-color mode though it's probably too slow, flickery and hacky to be practical.

EDIT 31-10
Bonus idea 2: Posted this in a comment:

The problem with these old cards is that they are SLOOOW, so you can't redraw the whole screen.
However, the computer is (relatively) fast, fast enough that some real-time "rating" of screen changes might be doable.
Thus, when fill rate is of concern (such as with a snowy CGA or a slow EGA), parts of the screen that are most different from what they should be are drawn first, and the parts that are "close enough" aren't drawn, thus lowering fill rate enough to maintain smooth motion.

Bonus idea 3: It might be possible to improve the ansi-from-hell LUT by using a better heuristic that can better preserve low frequency data (such as overall color of the block) even if at some cost to how many pixels are "wrong".
This comes to mind: Sum how different the chosen character and chosen pixel pattern are, if scaled down to a 1x1 image, then 2x1, then 4x2, then each pixel individually, potentially multiplying each "frequency error" by some factor to choose between a "blurrier" (as in with each charblock having the correct pixel count, but not caring much about where they are) or "sharper" (as in each charblock having most pixels correct, even if the overall color is wrong) image.
I'm not sure if python will be fast enough for this, though, the existing script is SLOOOW. I imagine some of it is due to using a general-purpose image lib for this, but I don't think fixing that would gain enough speed...

PS: I wonder if it could be possible to combine the colorfullnes of the 80x100@136 mode with the sharpness of the ansi-from-hell 320x100@16-ish mode, though I don't even know where to start with making that tranform in real time.

[FavoritoHJS]

resurrecting this thread for a new idea i have to speed up planar modes.

see, thanks to latches vram-to-vram copies are very fast, requiring 2 accesses (read and write) to fill all planes instead of 4

this could be useful for faster rendering! render a frame in two passes, one storing each unique 4-plane value combination, the other reading each location location, then copying it to all places with the same color.

we have a right to read vram however we want, and we better use it!

I think this is better explained with a diagram...

---

We want the same sequence of 4 pixels on addresses 0A, 12, 15 and 16.

First we find an instance of this value.
For double-buffering, one might be present in the previous frame, which could be used.
If one is not found, you will have to copy the value onto VRAM. Best to batch these writes up to reduce plane changes, and to write the fewest values possible - not unlike moving values normally.
In this case, we write to 0A, but NOT to 12, 15 or 16, as values will be copied there soon enough.
Then we read the value at 0A into the latches, and copy it to where it's required.

                                  /----------------------++-------++-++
                                 /\                      \/       \/ \/
  |00|01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10|11|12|13|14|15|16|17|18|19|1A|1B|1C|1D|1E|1F|
P0|  |  |  |  |  |  |  |  |  |  |44|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |
P1|  |  |  |  |  |  |  |  |  |  |25|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |
P2|  |  |  |  |  |  |  |  |  |  |44|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |
P3|  |  |  |  |  |  |  |  |  |  |28|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |

This totals 6 accesses instead of the 8 that would be required otherwise.
Additional copies of this value are much cheaper, only requiring 1 access to VRAM.

You could also do this with only 2 planes, though it requires more instances to be useful.
Additionally, this would give a lower speedup, as only 1 access is saved per instance.
However, this would be useful more often, as this only requires matching 2 planes, not all 4.

                                  /----------------------++-------++-++
                                 /\                      \/       \/ \/
  |00|01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10|11|12|13|14|15|16|17|18|19|1A|1B|1C|1D|1E|1F|
P0|  |  |  |  |  |  |  |  |  |  |44|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |
P1|  |  |  |  |  |  |  |  |  |  |25|  |  |  |  |  |  |  |xx|  |  |xx|xx|  |  |  |  |  |  |  |  |  |

Alas, this only useful for 256-color modes, where each plane value is a pixel.
16-color modes have the color split across the 4 planes, making this near-useless.

[dougvj]

Having SO many executables isn't that great, might be worthwhile to do some runtime-loading dynamic linking of the correct renderer.

I had the same thought, I have introduced a new executable for each new screen resolution for #81 and it's unwieldy. I can probably take this on

[viti95]

I think is possible to unify backbuffered modes in a single executable. The main issue with this approach is that the executable will be bigger, and that causes issues with devices with little RAM. The smaller the executable, the better, as more RAM is available for gamedata, avoiding acceses from disk. An option is to find some way to use dynamic libraries, and load required code as needed. This could very beneficial as sound code also takes a big chunk of executable size.

[dougvj]

There are apparently dynamic libraries in DOS but it seems like a complicated mess between compiler and extender support on first glance, which is important if we ever want to support DJGPP. I'll spend some time reading up on it and report back

[FavoritoHJS]

i recall that you can append data to the end of an exe file and it will not get loaded at execution time, so you can then open the executable file to load libraries
see: https://www.flipcode.com/archives/Data_Stored_In_Executables.shtml

[dougvj]

Great suggestion.

Should we roll our own linking? Honestly sounds like fun.