This is mainly a reminder for myself so I don’t forget what I did. When using Qodem in iTerm2 on my Mac along with a Microsoft Natural Ergonomic 4000 keyboard, the “Alt” key wasn’t working inside Qodem. It was impossible to “Alt-Z” to bring up the help, the dialer screen, or anything. I didn’t have this problem on my Macbook Pro. This is even after the standard swapping of Option and Command modifier keys in System Preferences. After much fiddling and even ssh’ing to/from my laptop to rule out anymore termcap issues like before, I finally figured out in iTerm2, going to Preferences, Profiles, Keys, General and changing “Right Option key” from “Normal” to “Esc+” fixed it. What’s even weirder is that I always use my left-hand modifiers to go into these menus and I have to select “right option key” from the list and not the left? Either way I don’t know what this does or why it matters, I just went with it.
Qodem for Mac (via Homebrew) disables serial port
Also Qodem installed from Homebrew disables the serial port. So if you want to use a real dial-up modem on your Mac, you gotta compile Qodem on your own. Fortunately it’s just a quick and easy ./configure ; make ; make install. I didn’t see in the git blame for the brew recipe any particular reason for disabling serial support, so maybe I should send a PR for it.
Boooooo serial support disabled by default in Homebrew
ANSI escape bug in Qodem
Bonus: while on the subject of Qodem, I think this one is a straight up bug that I need to submit a patch for (is it even maintained though?). I was testing a new door game GuTTerBoWl and noticed under only Qodem it spewed ANSI escape sequences to the screen. Actual original QModem, SyncTERM, MuffinTerm, and even Minicom didn’t do this, and rendered it correctly. The door author says he didn’t do any changes to the ANSI handling in the door kit (Angel Doorkit v1.0), nor had they seen this sort of output before and I believe them.
GuTTeRBoWl in Qodem
After looking at a capture of the ANSI output I noticed sequences such as ^[1;37m rendered correctly, but all the ones with no number before the semi-colon were not escaped and just sent to the caller raw like ^[;34m. Looking up some info on ANSI escape sequences, after the ^[ you can specify a mode such as change foreground/background text color, intensity, or blinking. If there are multiple modes, you can separate them with semi-colons such as ^[1;37m or ^[1;15m;20. This particular door kit was omitting a number when I presume it meant 0 or to reset modes.
At least according to wiki, a missing number is presumed to be zero (good lord there’s even a whole ECMA spec for this stuff):
All common sequences just use the parameters as a series of semicolon-separated numbers such as
1;2;3. Missing numbers are treated as0(1;;3acts like the middle number is0, and no parameters at all inESC[macts like a0reset code). Some sequences (such as CUU) treat0as1in order to make missing parameters useful.[5]: F.4.2
After figuring this out, it was pretty easy to reproduce this problem in Qodem:
Testing with and without mode numbers
This is what it’s supposed to look like:
GuTTeRBowl properly rendered in SyncTERM
Funny enough I ran a 1.5-something version of this game in 1995, I had forgotten all about it until the author released v4.00 last month.
