What is common between Norton tools such as DEFRAG/Speedisk, and That Editor? Both of them do something that is impossible: Pixel-by-pixel graphics in text mode. Obviously, somehow it has to be possible, because it was done, but how? Now some of you are too young to understand what’s the big deal, so let’s do a quick review on how the text mode works. To show graphics on the screen, your graphics card needs to have memory. Otherwise, it would forget instantly what it should be drawing. It has to remember every detail that is on the screen. Modern graphics cards have thousands of millions of bytes of memory on them, but things were very different with early graphics cards. The CGA, which came with the original IBM PC, only had sixteen kilobytes of memory. That’s literally hundreds of thousands times less than a typical graphics card on the market in early 2020s.

You could pack a hundred of these cards in a box, pack a hundred of these boxes in a pile – and your GPU would still have more memory than ten of these piles. The text-mode display on the CGA is made of 80 character cells side by side, on 25 distinct rows. Each of these cells is eight pixels wide and eight pixels tall. If we do some quick mathematics, that’s 128000 pixels. Furthermore, each of these characters can have 16 distinct colors – for both the foreground and the background. If this data was indeed represented as pixels, this would mean four bits per pixel, and the total would therefore be 512000 bits, or 64000 bytes because one byte equals eight bits. The poor CGA definitely did not have that much memory. It only had 16000 bytes, enough for only monochrome graphics at this resolution. To get around this problem,

they stored the text mode data differently. Instead of storing each individual pixel in the memory, they would only store character cells. Each of these 80×25 cells can only have one of 256 possible character symbols. Additionally, there is an attribute for each cell; the attribute can specify one of 16 distinct different foreground colors – and 8 distinct background colors, either blinking or not blinking. If we do some quick mathematics, this means 80 by 25 cells… each of which stores a byte for character and a byte for attribute… that is, two bytes per cell… Which works out to 80 times 25 times 2 bytes, which is 4000 bytes. Well within the limits. Phew, crisis averted! Unfortunately, this means that you cannot show arbitrary graphics in this mode. That’s what the “only” in “text-only mode” refers to. These 256 characters are what you have, that’s all.

Of course, some of these symbols are not so much text, and clever souls were able to utilize it for cool graphics. I even made a game using these graphics in February 1994, it seems. Actually, no, I did not make this. This game was written by Al J. Jiménez, but I unscrupulously edited the EXE file – and replaced the English texts with Finnish texts and took credit. Bad 15-years-old me, bad. Anyway, the text mode font was stored in read-only memory – on board the graphics card as bitmap graphics. Read-only means that the font could not be changed. The CGA was not actually the first display card – that came with the IBM PC. The first one was MDA; it only supported text mode and not graphics at all. Three years after CGA, they released the EGA, which we will skip now and jump straight to the VGA, which was released in 1987.

This graphics card was almost completely backwards compatible with the CGA, which means that it supported the same screen modes as the CGA did, but it also had a higher resolution text mode. This time, the character cells were not 8 by 8 pixels size, but 9 by 16 pixels size. The font was still 8 pixels wide; the ninth pixel column was just made by either doubling or blanking the previous column. The effective pixel resolution was therefore 720 by 400 pixels in the text mode, but the RAM requirements were still exactly the same: Just 4 kB for one screenful of colorful text. The text mode in this card had one significant difference to its predecessors: The font was no longer in read-only memory, but it was actually in regular RAM. When a text mode was selected, a font would be written in a specific portion of the RAM in the graphics card, and programmers could even replace that font with symbols of their own choice.

The most important use for this feature was to allow the use of so-called code pages. Different sets of 256 symbols for different languages. The standard code page 437 had a selection of symbols from European languages, some Greek symbols, a set of line drawing characters, and other symbols. But there was also code page 850, which replaced some of these line drawing characters with accented symbols. It actually had a full repertoire of symbols present in ISO-8859-1, a.k.a. Latin1, just in a different order. And there was code page 852, which was the same but for Latin2; code page 869 similarly for ISO-8859-7, a.k.a. ISO Latin Greek; code page 855 for Cyrillic; code page 860 for Portuguese; code page 862 for Hebrew; and so on. There were also programs that changed the font to look more stylish. This meant that you were no longer limited to the 256 symbols given to you from above.

Yes, you could only have 256 distinct symbols on the screen at the same time, but if you were willing to sacrifice some of those symbols for artistic purposes, you could do some cool things. This was not done often, but some programs indeed had a distinctive look because of that. [Music: Tu te reconnaîtras — Remix by Jani Tolonen — Composed by Claude Morgan] Here’s Scream Tracker, which used plenty of custom symbols. For example, these diagonal edges here were not part of any standard font, neither were these dots or these bars. These custom graphics were still subject to the same limitations – as any characters on the screen: For any given cell, you could only have one foreground color and one background color. And the cells would still each be the same size, and limited to the cell grid. For example, look at this screen. There are scroll bars and drive symbols here, but they are all in the 9x16 pixel grid,

You could not place these custom symbols arbitrarily. This is why the scroll bar jumps instead of moving smoothly. But hold on, the mouse cursor is not limited to those restrictions. It clearly moves pixel by pixel rather than cell by cell. How is that possible? Let’s have a look at That Editor, specifically, the DOS version. Here, PERSON smoothly strolls across the status bar every now and then. Now let’s open the font in the middle of the screen – and have a closer look at what’s happening when PERSON walks. See this? Right here. Something strange is happening here. Some of these character symbols animate and change as PERSON walks. I have sacrificed six symbols, namely C0, C3, C4, C8, C9, and CD, and replaced them with graphics. If you pay close attention, you actually notice that – sometimes a letter symbol appears in one of these cells. Let’s freeze the picture here.

Look, here’s an R right there. Why is it there? Now look at PERSON. He is walking right beside a letter R. If we place a grid over the screen, we can see that this cell, to the left side of PERSON, is actually exactly the same as the cell here next to C0. The next cell, is identical to the cell C3, and the next one, identical to C4. Here is what happens: First, the editor identifies the position where it would like to draw PERSON. It frames that position within character cells, and in a separate buffer, it draws PERSON in the same position. The result looks like this. Then, it reads the symbols that are underneath the position on screen – where PERSON should be drawn, and it reads them from the font, and places them in the temporary buffer, under PERSON. Then it writes the symbols back into the font, into these three slots. Finally, it replaces the characters in the title bar with C0, C3 and C4.

And it repeats this process 120 times in a second, producing animation. The font is literally being changed. If I copy and paste this C0 character several times here, you will see that every single one of them shows the exact same graphics. Now you may be wondering what’s those C8, C9, and CD used for, because I seem to use only three symbols. Well, look what happens when I change to 32 pixels tall font. Yeah, I added support for different animations, but this particular font doesn’t look very nice, so I almost never use it in my videos. What Norton and Symantec tools did with the mouse cursor – was exactly the same, except they did it not only horizontally, but vertically too. You would need to replace four symbols to do it. The developers of Norton Sysinfo anticipated what I was going to do. I created a file that includes all 256 symbols and tried to trick Sysinfo into displaying it,

but the program replaces many characters with periods to prevent exposing the trick. But naturally, I anticipated them anticipating my trick, so counter to their expectations, I created a countermeasure to countermand THEIR countermeasure, and now ALL of the font can be viewed in perfect clarity. What is interesting to me is how many symbol cells they used. For regular PERSON I needed three cells, because the animation was two cells wide and one cell tall, and for wide PERSON, I needed six cells, because the animation was four cells wide and one cell tall. But their mouse cursor is just one cell wide and tall. They should only need two cells horizontally and two vertically, that is four cells total. But they used six. The VGA text mode uses 9 pixel wide character cells, but the font is only eight pixel wide. For the line and box drawing characters, the VGA hardware duplicates the 8th pixel column to make the 9th,

and for others, the 8th column is just filled with background color. Norton used different characters slots for the right edge of the mouse cursor – depending on what’s under it. They did what they had to do. Oh, and I also noticed a weird bug. Here’s what happens if I place a few nul bytes on the screen. I painted these little blue stripes on the screen. They are full of nul bytes, that is, byte number zero. They appear as blank characters, but watch what happens when I move the mouse cursor over it. The program changes them into byte B2, and the character that is below it is also changed. The same also happens with bytes DF and FF when run under dosbox-X, but not when run under vanilla DOSBox. I don’t know why it does that. But now you know the secret. As you may know, four months ago, that is September 2021, I began studies in a university.

Because I want to complete the studies quickly, my schedule is very packed with like eight or ten simultaneous courses, which leaves me with almost no free time at all. Right now, it is the end of the year, and I finally have a few weeks to concentrate on something else than my studies, and I hurried to make this video. But that’s why I haven’t been posting videos lately. Sorry about that. I am only one person, and there are only 24 hours in a day. I still do read all of your comments and reply to most of them too, and I am fairly active on the Discord server too. And I will make more videos when I do have time. Have a very nice day, and see you again.

How I got Mario in That Editor — And how Norton Got 🐁

How I got Mario in That Editor — And how Norton Got 🐁

스크립트