In case anyone else is a fan of these unsual old displays, you might enjoy Posy's passionate videos which are a unique combination of curiosity, macro/slowmo shots and humor. Especially relevant is this one which is about what seems to be a very similar (but different sized) red/green/blue Casio CSF-7950 LCD: https://www.youtube.com/watch?v=jLew3Dd3IBA

OP here:

Feel free to use/to refer to it. I'm pretty sure, I'm not the first one to have come up with something like this. (My part in this is really in organizing the data and the related 6502 code for rendering, maybe the hot-one encoding for the lower 3 bits of the displacement offset to make this suitable for 8-bit processing.)

See “Sphere Mapping” by Frédéric Goset for further reference on compiling a static displacement map to render a spherical projection from a cylindrical one: http://fredericgoset.ovh/informatique/oldschool/en/spheremap...

BTW, I'm now using 32 × 100 pixels (or rather, data points), which doesn't change much, other than adding a few bytes to the data stream for the world map (we're just adding 4 columns or 16 bytes to this).

BASIC is about 1000 times slower, so there's no way we could do this in realtime. Moreover, as mentioned in the article, the original PET 2001 suffers from bus conflicts when the CPU and the video circuitry access the video memory at the same time, because of slow SRAM, which is just the same speed as the CPU. To avoid this, the BASIC used by these earlier models prints only during the vertical blanking interval (V-BLANK), when video is off. This is only about a quarter of the duty cycle, where PRINT can actually happen, slowing this down to a fraction of what BASIC could theoretically achieve.

Let's do some nerdy numbers: ;-)

We may try rendering this to static slides and store them as strings in DATA statements. At 16 cols and 16 rows, this is 256 bytes per frame and there are 100 of them (the current map width), which makes 25 KB. We'll also need memory for the overhead of this as BASIC lines, which is 2 bytes for the line number in binary, another two bytes for the link to the location of the next line in memory (a 16-bit pointer), 1 for the "DATA" token, and a zero-byte as the line delimiter (EOL), which makes 6 bytes per BASIC line. And we'll need another two bytes for the enclosing quotes per string, and one for a separating comma (if we put more then one string in a given line).

Assuming we store 3 strings in a line (of max 80 characters), this makes a total of 533.3 × (6 + 3 × 18 + 2) = 33,064 bytes (or 32.29 KB), the memory requirement to store just the DATA lines. – So there's no way to fit this into a machine, which maxes out at 32K in its most luxurious memory configuration (or 16K for the original PET 2001).