For a while I've wanted to be able to capture various outputs of the emulator to files for offline use. My prior filesystem corruption problem took precedence over any features that involved writing to the filesystem, but since that got resolved, I feel more free to implement some of these other things.
Most of these capture features are imagined to dump to an automatically named file based on a prefix and sequence number so as to avoid overwriting existing stuff, and keep it ordered. This would require some machinery to be created find the highest sequence number to use within the context of a prefix and for a given directory. Since directory enumeration is rather slow, I wanted to keep a persistent 'index' to give a hint as to where to start the numbering. When a new file names is to be generated, it can start at the value in the 'index', and then bump the number. The index is not required, but it speeds up the generation process by giving a start point that is likely to work, thereby avoiding a bunch of directory traversal. Since I had just finished implementing a config file reader, and which has writing capability, I decided to simply reuse that format for the 'index' file.
Since the TRS-80 display is a character array (as opposed to a pixel array), it is very straightforward to dump the video buffer to a text file. However, there are a couple quirks:
- the TRS-80 (allegedly due to a bug) oftentimes puts chars 0x00-0x1f instead of 0x40-0x5f in the video buffer. Visually, this is not confusing, because they render the same, but from a binary standpoint of course this looks like gibberish. I fixup those character ranges so they read sensibly in a text editor.
- the character array implicitly word-wraps at col 64, so I add linefeeds at the end-of-line so again it looks sane in a text editor.
- the character set of the TRS-80 contains a few unusual characters (e.g. arrows), and then of course all the semi-graphics characters. These aren't going to render at all without some help.
The first two quirks were easily coded around, but for the third I found a font which contains the TRS-80 Model I semi-graphics characters (actually they have the full TRS-80 Model I character set). This is the AnotherMansTreasureMIB64C2X3Y.ttf TrueType font, to be had at:
(along with many others).
To pull this off, I have another screen capture mode which emits a UCS-2 LE file, and which translates the semi-graphics and special characters into the Unicode range e000-e0ff. So, for those screen captures, you can open them in some editor that allows you to choose the font, and you can now see the TRS-80 screen in it's normal state. Also, since this is text, instead of a bitmap, you can cut-paste the text for your cut-and-pasting pleasure. If your editor has the ability to 'embed fonts' (e.g. Word, LibreOffice), then they can be viewed correctly on other machines even if they don't have the particular font installed.
Here's a few sample captures:
I have to post these as png because I can't embed the fonts on the web such that plaintext would make sense, but as you can see, I highlighted some of the text (the blue stuff) so that you can more easily see where the character boundaries are located in the textual screen capture. (The green and black obviously is just my specifying the text foreground and background colors, for visual effect).
Anyway, I imagine this will be helpful for when I get around to producing some sexy documentation. If nothing else, I can stop using my phone cam to take pics of the screen for these logs!
Here are a few others for your retrocomputing viewing pleasure. This is how we did it in the 1970's:
The screen cap function is bound by default to F8 for plaintext, and shift-F8 for unicode translation (for use with the special font). Like the other bindings, you can alter them via config file. Anyway, each time your press F8, it will generate a new sequentially numbered file in the 'scrcap' directory. The naming schema is 'STnnnnnn.TXT', where 'nnnnnn' is the sequence number. (There will be a seq.idx file there as well; ignore it. It is the hint of where to start numbering.)
Later, I'll probably do a bitmap version as well, but that will involve lots more bit-fiddling work than the text mode. This will do for quite a while, but I'm eager to eventually get bitmap working for a variety of reasons, amongst which are that it is the only way to capture the HRG1B output.