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).