Actually forget, xterm is unusable, even basic copy-paste between OS X apps and xterm doesn't work.
I'll hack out a keyboard mapping later for a slightly more modern terminal.
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:54, Sampsa Laine <sampsa at mac.com> wrote:
OK, xterm works pretty well after some investigation..
I've never before attempted to change the setting of an old-skool X program and it looks like an absolute nightmare. Could any of you gurus produce an .xtermrc with a beige background and black text and font size set to 14?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:13, Sampsa Laine <sampsa at mac.com> wrote:
Actually xTerm has SOME of the mappings defined by default, does anyone have a decent .xtermrc file for all of them?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:05, Sampsa Laine <sampsa at mac.com> wrote:
On 5 Jan 2014, at 17:53, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Where are the config files for xterm stored? I want it to look less 1982 and have a font that doesn't require a microscope to read.
sampsa
OK, xterm works pretty well after some investigation..
I've never before attempted to change the setting of an old-skool X program and it looks like an absolute nightmare. Could any of you gurus produce an .xtermrc with a beige background and black text and font size set to 14?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:13, Sampsa Laine <sampsa at mac.com> wrote:
Actually xTerm has SOME of the mappings defined by default, does anyone have a decent .xtermrc file for all of them?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:05, Sampsa Laine <sampsa at mac.com> wrote:
On 5 Jan 2014, at 17:53, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Where are the config files for xterm stored? I want it to look less 1982 and have a font that doesn't require a microscope to read.
sampsa
Actually xTerm has SOME of the mappings defined by default, does anyone have a decent .xtermrc file for all of them?
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 19:05, Sampsa Laine <sampsa at mac.com> wrote:
On 5 Jan 2014, at 17:53, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Where are the config files for xterm stored? I want it to look less 1982 and have a font that doesn't require a microscope to read.
sampsa
On 5 Jan 2014, at 17:53, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Where are the config files for xterm stored? I want it to look less 1982 and have a font that doesn't require a microscope to read.
sampsa
Yeah, thinking of going that route, even though Xterm does look like crap and isn't really well integrated into the rest of OS X.
As a bonus, I'll get Erik's SIXEL support too..
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 5 Jan 2014, at 17:53, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
Why don't you use xterm? The mappings are already correct. And as a bonus, you actually get a VT100 emulation with less bugs.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
http://www.vt100.net/docs/vt220-rm/
On 2014-01-04 21:08, Sampsa Laine wrote:
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
sampsa <sampsa at mac.com>
mobile +44 7961 149465
/G ran
Been playing remapping some "slime slim, full size Apple" kbd but the results aren't great. Does anybody have a canonical list of VT220 escape codes, preferably in hex (I think my term's escape sequence is broken)..
sampsa <sampsa at mac.com>
mobile +44 7961 149465
On 2014-01-02 16:45, Paul_Koning at Dell.com wrote:
On Jan 1, 2014, at 12:16 PM, John Wilson <wilson at dbit.com> wrote:
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
RSTS doesn't have loadable drivers, so it all has to be genned into the
system (and user-written drivers aren't officially supported). On the plus
side, RSTS autosizes the system on every boot (including floating CSRs, and
all vectors except card readers are autodetected so they don't need to follow
the rules at all -- user-written drivers would have to be hooked up to this
too), and passes CSR/vector/model information to the drivers that it enables.
So while RSTS requires the drivers to be linked to the system, it's not a
totally rigid mass that works only on the exact config it was built for.
You can run a monitor on totally different hardware and as long as it has
drivers for enough of the existing peripherals to work, you're all set.
Also, you can have multiple monitors (built different ways) on the same
pack and tell the pre-boot thingy (INIT.SYS) which one to boot.
A good example is the monitor called sysgen which is the one on the system installation tape. It s a bit like the Unix Generic kernel. It s built to support one or two units of every supported mass storage and distribution device, plus a terminal line or two. That way, a single kernel works for every system on which a customer might want to install. You then run that monitor to build your own, which would normally have a more selective set of mass storage devices, the non-disk/tape I/O devices on your system, and support for more jobs. But in all cases, you can build a monitor for more hardware than you have, and whatever is missing is simply disabled at startup.
As for loadable drivers, true until late in the RSTS evolution. Somewhere in the V9 era, I believe, the terminal driver system was redone so it has port drivers for each terminal interface type, which are loaded at startup as appropriate for the hardware you have. That s not a general mechanism, though.
In fact, RSTS has 3 or 4 quite distinct driver types: disk drivers, terminal drivers, network device drivers, and other device drivers. Network and other are somewhat similar, but terminal port drivers and disk drivers have no relationship at all to regular device drivers.
User written drivers no such thing. In theory you might be able to, but only with a source kit which few people did. And there was no documentation for this. It may be that one or two people wrote an other driver; I can t imagine user written disk drivers.
A friend of mine worked on a TCP/IP implementation for RSTS/E. It got as far as having working IP, ICMP and UDP (and ARP), as far as I know, but I'm not sure exactly how he hooked the whole thing into RSTS/E in general.
I have his code somewhere, if someone would be seriously interested in looking at it, or do some work. I think it's for RSTS/E V8...
The "sysgen" monitor for RSTS/E sounds somewhat similar to the Baseline system for RSX, which have a few of everything compiled in. That system is mostly used just as a start to do a proper SYSGEN for a system tailored to your specific hardware.
RSX also marks devices that don't respond as offline, which is pretty much just like disabling them.
Writing your own devices drivers in RSX, however, is very well documented, and supported. There is a whole manual that only deals with that specific topic.
Writing your own ACPs however, is not that well documented, even though the interface is actually very clean. There were DECUS papers published about writing your own ACPs instead.
Johnny
On Jan 1, 2014, at 12:16 PM, John Wilson <wilson at dbit.com> wrote:
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
RSTS doesn't have loadable drivers, so it all has to be genned into the
system (and user-written drivers aren't officially supported). On the plus
side, RSTS autosizes the system on every boot (including floating CSRs, and
all vectors except card readers are autodetected so they don't need to follow
the rules at all -- user-written drivers would have to be hooked up to this
too), and passes CSR/vector/model information to the drivers that it enables.
So while RSTS requires the drivers to be linked to the system, it's not a
totally rigid mass that works only on the exact config it was built for.
You can run a monitor on totally different hardware and as long as it has
drivers for enough of the existing peripherals to work, you're all set.
Also, you can have multiple monitors (built different ways) on the same
pack and tell the pre-boot thingy (INIT.SYS) which one to boot.
A good example is the monitor called sysgen which is the one on the system installation tape. It s a bit like the Unix Generic kernel. It s built to support one or two units of every supported mass storage and distribution device, plus a terminal line or two. That way, a single kernel works for every system on which a customer might want to install. You then run that monitor to build your own, which would normally have a more selective set of mass storage devices, the non-disk/tape I/O devices on your system, and support for more jobs. But in all cases, you can build a monitor for more hardware than you have, and whatever is missing is simply disabled at startup.
As for loadable drivers, true until late in the RSTS evolution. Somewhere in the V9 era, I believe, the terminal driver system was redone so it has port drivers for each terminal interface type, which are loaded at startup as appropriate for the hardware you have. That s not a general mechanism, though.
In fact, RSTS has 3 or 4 quite distinct driver types: disk drivers, terminal drivers, network device drivers, and other device drivers. Network and other are somewhat similar, but terminal port drivers and disk drivers have no relationship at all to regular device drivers.
User written drivers no such thing. In theory you might be able to, but only with a source kit which few people did. And there was no documentation for this. It may be that one or two people wrote an other driver; I can t imagine user written disk drivers.
paul
