ziggurat29For 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:
http://www.kreativekorp.com/software/fonts/trs80.shtml
(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.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Screen capture (F8) captures the TRS-80 screen even if the Help screen (F1) is shown. I thought one could capture the hypervisor screens etc.
Are you sure? yes | no
that's an interesting point! The hypervisor works out of the context of the TRS-80 screen memory (in Z-80 space), so that's probably why that it. I will have to think about it. I plan to eventually do a graphics capture as well, which would certainly capture that stuff, since it would ostensibly work off the video frame buffer.
Are you sure? yes | no
OK. Another thing, this F8 and Shift+F8 should perhaps be seen in the F1-screen and README.txt. Maybe it would be better to use the PrtSc key for screenshots, and maybe Alt+PrtSc could be one type of screenshot. Ctrl+PrtSc can still be SysRq. (I know PrtSc is now some debug window.)
Are you sure? yes | no
Lol, yes, updating the F1 is a to-do. It has always been a hard-coded help screen, because the key assignments were hard-coded. But now they are dynamic and can be changed in trs80.cfg, so I need to do a little more coding there to dynamically set the text according to the effective settings. Frankly I had hoped no one would notice until I got that fix in, but you caught the defect before I could do so!
Regarding PrtScn -- I tend to agree, and I regret very much ever attempting to use SysRq, Pause, and friends for any of the hypervisor functions. Those buttons have a lot of quirks, including:
* keyboard manufacturers may not even present those buttons at all. When I first wrote the code, SysRq seemed sensible to me for a hypervisor, since it is a 'system request', but I have some keyboards where you cannot generate this keystroke at all. I did not know about the deeper PS/2 quirks until I had gotten deeper into implementation.
* and that button in particular has implicit shift key states. even though you aren't pressing any of the shift keys (e.g. ctrl, alt, shift), the keyboard emits those keystroke sequences as if you did, and if you /do/ press one of those buttons, you get a different scan code. It's one of several weird PS/2 things with those keys, and is probably why they aren't used much in real life (and why manufacturers have incrementally removed them from keyboards. 'Scroll lock', anyone?)
Anyway, PrtScn. You can totally use PrtScn (within reason) to do your screen caps instead of F8. But you found my super-secret undocumented 'debug info' key that for some reason I chose to attach to the 'PrtScn' by default, and that attachment will get in the way of your assigning it to the screen capture functions. This can be changed in the trs80.cfg, though. There is an equally undocumented default setting:
"debug= PrtScn #in debug builds; you never know"
that you can can change to
"debug= None #in debug builds; you never know"
to get it out of the way, and then you should be able to use PrtScn, cPrtScn, and sPrtScn for other things. That button does random things according to my mood. In retrospect, I should have assigned it to something more random like 'casF12', but that was 3 years ago, and alas the deed is done.
In other news, I wish I had chosen 'unicode' mode as the non-shifted text capture mode (F8), because the output is so much more interesting when viewed with the the trs80 font than the 'ansi' mode. ANSI mode is really only interesting in a hex editor, and of very limited use at that. I should have reverse the 'shift' aspect. But anyway, once again, it is now all just a config file change away.
Are you sure? yes | no