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
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
Oops. Just found 'em up on bitsavers. Let's hope it's helpful with test
point values. I have no idea if TP1 should be 2.4008VDC or it should be a
specific waveform.
I took a look at the schematics. Something around 2.5VDC looks reasonable
for TP1 when nothing much is happening, because of the potential divider
formed by R2 and R3.
I guess you have already checked that the motor is free to turn?
It looks like the motor is probably connected between J11 pins 3 and 4. Do
you have more than a few volts DC between those pins?
It looks MPWR (connector J4 pin 3) is the signal to tell the motor to run.
You should have something over 0.7VDC here for the motor to run.
What have you got at TP4 - you would need a few volts here too.
What about TP5? It should be 0V when the motor is stopped and a small DC
voltage when it is running. If there is more than half a volt or so here,
check whether R15 is hot.
Regards,
Peter Coghlan.
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
Hello!
It'll work. But you need to worry about the timing.....
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Jan 1, 2014 at 8:41 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Wed, 1 Jan 2014, Cory Smelosky wrote:
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
Oops. Just found 'em up on bitsavers. Let's hope it's helpful with test
point values. I have no idea if TP1 should be 2.4008VDC or it should be a
specific waveform.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Wed, 1 Jan 2014, Cory Smelosky wrote:
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
Oops. Just found 'em up on bitsavers. Let's hope it's helpful with test
point values. I have no idea if TP1 should be 2.4008VDC or it should be a
specific waveform.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Evening,
Do RX50 schematics exist on bitsavers, fiche, or elsewhere? I have one
here and it doesn't appear to work. Testing is showing either a busted
motor or something wrong in the voltage control stuff.
Thanks!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-01-01 21:32, Jerome H. Fine wrote:
>Johnny Billquist wrote:
In M+ the ability is even better, as device driver loading and
unloading is not related to devices being online or offline.
RT-11 has the same ability. A hard drive can be online
without the device driver being LOADed. If a background
program requests access to a drive, the program can perform
a temporary .FETCH to bring the device driver into memory
and then .RELEASE the device driver when finished. A system
job can't request RT-11 to perform a FETCH, so any disk
drive needed by the program must have the device driver
LOADed before the program uses the disk drive. In theory,
a system job could pause and the user could then LOAD
the device driver just before the system job uses it. MACRO-11
always attempts a .FETCH when a device driver is not already
LOADed.
Ah! Now I know what you are talking about. It's the same in OS/8.
And no, this is not at all the same thing as in RSX.
(If I have things wrong here, I apologize, since now I'm going to make a comparision between RSX and OS/8, and assume that RT-11 indeed do work the same.)
A FETCH loads a device driver from disk into memory. It's an operation you do before performing any I/O to the device. However, you can only fetch a device driver that is known to the OS. The device driver is installed by a different process, which just makes the system aware that the driver exists. You also get some sort of handle in return from a fetch, which is what you use to do I/O to the device.
In RSX, LOAD means installing the device driver into the running system. Prior to the LOAD command, RSX have no clue that the device driver exists. You never have a device driver as a part of your own address space, and several tasks can do I/O to a device concurrently.
When a device driver is loaded into the system, all device driver databases are populated, and the actual code get put somewhere in memory. Don't care where. The LOAD command do that fiddling, and the device driver databases holds enough information that the OS then can invoke the driver when needed. LOAD is a user command, which do a lot of complex operations, and is not something any program ever do on its own. It's a user initiated operation to install a (new) device driver into a running system.
However, for I/O to actually go through to the device, it must also be online.
Online can mean *two* things. The physical device itself (which is what you talk about, Jerome) must obviously be online. But the device must also be online from the driver point of view, which is a separate question. You can load a device driver in RSX, but if a physical device is not present to match it, the device driver will be offline, and any I/O to it will fail before it even comes to the device driver code.
If a physical device later comes online, the driver database does not necessarily become updated to be online. So you can have a physical device online, but still have the device driver offline, but loaded.
Unloading a device driver in RSX means that the driver code is removed from memory, the device driver database marks the device as offline, and that's it. Any memory used by the device driver is freed, so it can be used by other things, such as programs. However, the device driver database is not removed. It's not feasible to remove all possible references to the database.
So, in RSX, all programs can always do I/O to *all* devices known to the system. And without any special preparations or setups. LOAD is for adding even more devices to the known list.
(all within the restrictions of protection and device allocation, of course, which can restrict access)
Not sure exactly what your distinction between unload and remove is.
In RSX terms, you LOAD and UNLOAD device drivers. In 11M, an implicit
online of a device is done when you load it, and offline is done on a
device before unloading it. In M+ the offline and online steps are
separate commands, which just requires that a device driver is loaded.
In RT-11, a device driver must be INSTALLed and the
name placed into the Permanent Physical Device Table
before a LOAD can be performed. The INSTALL code
checks that the device driver is compatible with the
operating system parameters, among other things. A
user may then UNLOAD and REMOVE (in that order)
a device driver if a different version of the device driver
is needed, such as for testing a new version.
Yes, I see where you are coming from now. So, the RSX LOAD (which is done on the running system) is actually equivalent to the INSTALL in RT-11. There is no equivalent to the RT-11 LOAD, all devices are always available.
Even more fun is M+ is that device drivers do not need to be
recompiled if you recompile the kernel. Device drivers are totally
independent of the kernel.
Likewise in RT-11. In fact, I believe RT-11 has always
been that way.
Remember, I'm talking about the equivalent of RT-11 INSTALL here... Ie, I can do a SYSGEN, and build a totally new RSX system, but still use a device driver from a previous SYSGEN just fine. Even though the new kernel have different stuff compiled in, and databases and routines have moved to different addresses.
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
I think RSTS/E is less flexible, from what I can remember.
TSX-Plus is similar. All device drivers must be LOADed and
permanently resident at boot time.
So, how is it with RT-11. Can you INSTALL a new device driver into a running system and use it, without performing a reboot?
Johnny
