The key thing about this [original] design was that each nibble corresponds to a pixel. Each nibble stores the data, the sync, and the pixel clock.

So, if I keep with this design intent, then reducing the storage capacity, by increasing the physical size of the nibbles [e.g. by 8x], there inherently will be fewer pixel-clocks. Thus the display will have to be driven with a smaller resolution than designed-for.

Since the display is directly-refreshed (there is no scaler), this means there'd be a picture 1/8th of the screen-size either in the upper left corner, or filling the top 1/8th of the screen-height. Or maybe something inbetween, but still only filling 1/8th of the pixels. NOT stretched across the screen, like MarioThing, of the last log.

----

The original design-intent also included the idea that read-back could be entirely implemented with a handful of logic chips; four outputs of a counter, for instance, could be directly wired to the three color inputs (8 colors, one bit for each of RGB) and to Hsync.

The readback-logic has grown a little due to synchronization (determining which /RD pulse corresponds to the start of a PWM-nibble, and which to the nibble-value). But, still, the data is wired directly to the counter outputs.

Now there's some plausibility I might wish to do some scaling... Can that be handled with a minimal amount of additional logic?

Meh, sure... The counter is already clocked at 16x the nibble-rate, so a latch to store the data output, then the 16x clock could be used to feed the pixel clock. OK... Not bad.

So, say, we've managed to only store 1/16th of the data originally planned... Could stretch each image/data-pixel across 16 physical pixels. Vertically, the resolution would still be 160 pixels tall (image and data). Horizontally, the image would be 240/16=15 pixels, stretched across 240 physical pixels.

Were I to try to implement MarioThing, it could be done by storing every row 10 times to make for 16 image-pixels vertically. But, horizontally we'd be short an image-pixel. Meh. Anyhow, 1/16th of the capacity isn't set in stone. Maybe I could get away with PWM-nibbles that are 15x the length of those originally-planned.

OK, now it can still be done with a handful of logic. But, now, instead of driving the LCD's pixel-clock once with each nibble, it needs to be 15 times with each nibble... and... the logic increases in complexity, again. OY.

AND WHOOPS:

no, the counter is clocked *way* faster than 16x the nibble-rate,.. because of the start and end buffers. More complexity, still!

Fact is, I'm using a uC, due to supplies and space, so it shouldn't be difficult to pulse the pixel-clock pin 15 times after each nibble is read... but this all takes away quite a bit from the original intent of an LCD wired to a floppy drive through a counter.

So... I got a little carried away anyhow. Back to just storing and reading back PWM-nibbles containing audio, then going from there.