These sessions are in bsdutils 'timed script' format, with each session having two files: a .tim file - containing timing information - and a .txt file, with the main text. The text file can be read without having to sit and wait for the session to 'play back', which you can do with the bsdutils 'scriptreplay' (used to be called 'replay') command. An example of usage (typed input is in bold face):
lex@desree:Timed_Sessions$ scriptreplay sparc_on_fire-310809-123049.tim sparc_on_fire-310809-123049.txt lex@idoru:Desktop$ date Mon Aug 31 12:30:50 BST 2009 lex@idoru:Desktop$ # 80x30 xterm (screen)That session gets off to a slow start but by the end of it, there is smoke pouring out of the power supply of my old SPARCserver 630MP, with me running around switching things off and opening windows - probably not the best thing to do when faced with a fire, but my tendency is to panic. This is the first sign of trouble:
Aug 31 12:38:41 sparrowhawk su: 'su root' succeeded for lex on /dev/pts/0Any security information in these transcripts is probably useless now, and I should warn you that some of them (cd32sesh2) contain bad language and crudity - mostly by me - and the occasional personal identifier (folks' names and old-format telephone numbers for long-extinct BBSs).
le0: No carrier - transceiver cable problem?
Hello, Innocent! I miss you and wish you were back on MUD, but it's not the same now, I know. <sniffle>. Other people whom I miss: Skiff, Boogs, Katamati, Rainbow (passed-on, sadly - and when I finally contacted him, I was in rather a psychologically messed-up state - rather a strange time for me, that was).
The personae that were on my account were:
The original sessions were in a multiplexed text/timing format from an Amiga HiSoft BASIC application called 'Timeterm.bas' - one of my many kludged-up programs to do something specific. I'd used bsdutils with NetBSD, which was one of the first non-Windows operating systems that I used. bsdutils had a program called 'script', which opened a shell and recorded the session, with optional timing information. When I went back to AmigaDOS, I looked for a similar application and could not find one, so I wrote my own. The program listing contains very few comments, but I was able to write a rough translation program to turn the TimeTerm files into bsdutils 'script' format.
Some of these are unreadable in a normal text viewer - an example: Mud170595.txt - because of the ANSI escape sequences and line noise.
Here's a bunch of stuff - I'll leave you to sort the wheat from the trees..:
*.info: AmigaDOS icon
*.log: ASCII text
*.lst: ASCII text listing
*.tt: original Timeterm files
*.tim: bsdutils script/replay timing file
*.txt: ASCII text, with ANSI escape sequences
Although the TimeTerm.doc.txt file shows you how to use the program, it does not explain the format. Simply, a TimeTerm (.tt) file is a sequence of multiplexed text and timing information. The file starts with an identifier ('*ttm20') and the current date and time. Incoming serial text - from the modem - is then interspersed with timing information, in this format:
0xFF [t3] [t2] [t1] [t0]Where '0xFF' is CHR$(255) - for you BASIC freaks - and '[t3] to '[t0]' are the most-significant byte through least-significant byte of the amount of frames (1/50th second) that have passed since the last 'time event'. My translation program does a bit of masking and rotation to get things in the right order, since I don't know whether C has an operator to reverse the order of bytes in a long-word. It probably does - buggered if I know.