• Please review our updated Terms and Rules here

Simple data acquisition using RT-11

G

GreyHairedDECfan

Experienced Member
Joined
Dec 5, 2021
Messages
127
Location
Northern Maryland
What would I need to use in order to do some simple data acquisition (dry contact and RTD inputs) and be able to read the status/values via RT-11? Currently I'm running it on simh, so I'm thinking a USB-connected data acquisition module, like this one:


Do I need some sort of driver, or can RT-11 directly access something like that using either BASIC-11 (which I already have) or Fortran (need to install)?
 
There will be ways if your interface 'looks like' a serial terminal and can be driven like a TTY.

If not, you will have to write a device driver to make it work.

We used bespoke languages at work (the CEGB in the UK - SWEPSPEED and CUTLASS) which ran on 'bare metal' LSI-11 / PDP-11 machines that could monitor and control power stations. These languages were interfaced to terminals, colour graphic display cards, touchscreens, mice and trackballs and various plant I/O equipment. Some of this equipment required bespoke QBUS interface cards and device drivers whereas some (such as the Solatron IMPs) were interface via serial lines and could be driven by our standard terminal driver. However, our terminal driver could handle both ASCII and BINARY transfers with FIXED or VARIABLE lengths depending upon what we were communicating with.

Other types of I/O equipment just appeared as registers in the QBUS I/O space - so could be directly written to and read from by our equivalent of the BASIC PEEK and POKE statements (actually MEMIN and MEMOUT).

I am trying to get this code released...

Dave
 
If you need low level device access in RT-11 note that you can also link assembly language routines into BASIC-11 and call them as subroutines.
See - DEC-11-LIBUA-A-D_BASIC-11_RT-11_Users_Guide_Mar78.pdf
 
wa2flq said:
If you need low level device access in RT-11 note that you can also link assembly language routines into BASIC-11 and call them as subroutines.
See - DEC-11-LIBUA-A-D_BASIC-11_RT-11_Users_Guide_Mar78.
Click to expand...
Yes, I saw that in the BASIC-11 manual. Good to know, though I readily acknowledge that something like that is way above my skill level. That's why I'm hoping I can find a simpler way to accomplish this.

My background is commercial temperature controls, starting in the early '80s. I just want to be able to read a few digital inputs and temperature sensors around the house.
 
daver2 said:
There will be ways if your interface 'looks like' a serial terminal and can be driven like a TTY.

If not, you will have to write a device driver to make it work.

We used bespoke languages at work (the CEGB in the UK - SWEPSPEED and CUTLASS) which ran on 'bare metal' LSI-11 / PDP-11 machines that could monitor and control power stations. These languages were interfaced to terminals, colour graphic display cards, touchscreens, mice and trackballs and various plant I/O equipment. Some of this equipment required bespoke QBUS interface cards and device drivers whereas some (such as the Solatron IMPs) were interface via serial lines and could be driven by our standard terminal driver. However, our terminal driver could handle both ASCII and BINARY transfers with FIXED or VARIABLE lengths depending upon what we were communicating with.

Other types of I/O equipment just appeared as registers in the QBUS I/O space - so could be directly written to and read from by our equivalent of the BASIC PEEK and POKE statements (actually MEMIN and MEMOUT).

I am trying to get this code released...

Dave
Click to expand...
So reading the comments on the seller's webpage, it looks like this may work (as you described a TTY):

This is a very easy-to-use device, but the description is vague about the exact details of operation. Simply plug the device into a computer's USB port, and it implements a serial communication port connected to a device that continually sends data that describes the voltages present on its ten input channels. This data is sent at 115200 baud rate. The serial port (or the program that you use to read data from this serial port) will probably need this rate information to correctly receive data.

The data format looks something like this:

CH0:2010 1.620V
CH1:2187 1.761V
CH2:2013 1.621V
CH3:2192 1.766V
CH4:2014 1.622V
CH5:2187 1.761V
CH6:2006 1.615V
CH7:2178 1.753V
CH8:2003 1.612V
CH9:2181 1.757V
[empty line]

where the white space in these lines is actually a single tab character. Each line ends with the two characters "carriage return" and "linefeed".

I would think I could write a simple Fortran or BASIC-11 program to read the incoming data and parse it into whatever format I want. Does this make sense?
 
Makes sense to me if indeed it does provide data in that format. How do you know when data is available though? What if nothing is ready? How often does it provide data?
 
tradde said:
Makes sense to me if indeed it does provide data in that format. How do you know when data is available though? What if nothing is ready? How often does it provide data?
Click to expand...
Apparently it just repeats - it sends the data (the values of all channels) repeatedly at some interval (IIRC every 2 seconds). If you open a terminal program such as puTTY, it'll just show up on that screen every couple of seconds.
 
Last edited:
It looks like the NOYITO device transmits a set of 10 readings at regular intervals, the default being every 500ms (it implies that this can be changed).

Currently I'm running it on simh
Click to expand...

How trivial it will be to read from it in a Fortran/BASIC program running on RT-11 running on SIMH is going to depend on a number of factors.

If we assume that the USB serial device can be attached to a simulated serial device on the simulated PDP-11, such as an additional DLV11-J or DLV11-E interface, and that there are no "gotchas" with the SIMH simulation...

You might then be able to poll ("peek") the characters as they come in (with a bit of "application start-up synchronization" by the looks of it); if you can complete whatever processing you want to do before transmission of the next set of values starts. It was not clear that there was accessible "flow control" (but I didn't look that hard at the details of the NOYITO device). Whilst polling code would be simple, failing to poll and retrieve the next character/characters in time on real hardware (DLV11-J for example) would result in an overrun in the receiver. The same might be true of the SIMH simulation; although if the SIMH PDP-11 is running faster than a real system it might be far more capable, and there might even be extra buffering between the USB serial device and the simulated PDP-11 device.

Application [start-up] synchronization: you are reading a data block once you have detected "CH0:" (based on the example above).

Also a lot probably depends on how SIMH implements things (in terms of providing, say, a simulated DLV11-J, DLV11-E etc)..

Based on my experiences of 11/03 and 11/23 systems in the 80s and 90s (RT-11 and RSX-11M), this sort of activity on real-hardware can require an Interrupt Service Routine that places incoming characters/data in a ring buffer (or buffer set) to be retrieved by the application, especially at the higher speeds and/or when the program performs some kind of non-trivial processing and/or writes the data to disk, and, in this case, maybe also if you went for an increased sampling rate. On RSX-11M it definitely ought to be done that way (other users/processes on the system)! I did these ISR buffering things in assembly language (MACRO-11); which were then used from Fortran.

It might be that this latter approach would be needed on a SIMH PDP-11 as well; it might be worth trying to check on that...
 
kb811 said:
It looks like the NOYITO device transmits a set of 10 readings at regular intervals, the default being every 500ms (it implies that this can be changed).



How trivial it will be to read from it in a Fortran/BASIC program running on RT-11 running on SIMH is going to depend on a number of factors.

If we assume that the USB serial device can be attached to a simulated serial device on the simulated PDP-11, such as an additional DLV11-J or DLV11-E interface, and that there are no "gotchas" with the SIMH simulation...

You might then be able to poll ("peek") the characters as they come in (with a bit of "application start-up synchronization" by the looks of it); if you can complete whatever processing you want to do before transmission of the next set of values starts. It was not clear that there was accessible "flow control" (but I didn't look that hard at the details of the NOYITO device).
Click to expand...

Addendum notes.

Thinking about the question of using standard I/O functionality (READ/WRITE line at a time in Fortran): if you have a device that keeps chucking data at the system and there is way to control the flow, then things may overrun if the application cannot deal with things fast enough. I don't think DLV11 driver's buffer was particularly large. Which is why I would have resorted to ISRs back in the day (slow machines, lots of data, no flow control).

The SIMH PDP-11 may be so fast it does not matter.

I never used BASIC on RT11; but imagine similar issues could be present.

I wonder if the NOYITO device has any more control functions? For example: the ability to "request" data? Another possibility is it runs at the "high baud rate", but is in fact slow at sending the lines... The documentation for it seems a bit sparse.

The device looks "cheap" (< £20 here in the UK) so trying it out should be relatively straightforward and a good way to really find out what's possible and how.

Also, this looks like one of those multiple brand things. The following looks like the same device under a different brand:

https://www.amazon.co.uk/dp/B08DL2YXGN
 
After thinking about this for a while, since I'm emulating anyway, this might be a good excuse to switch to Raspberry pi hardware. I/O boards and such are plentiful for them. Probably a better way to go than using a USB device plugged into my PC, though I still have the challenge of getting RT-11 to talk to the I/O on the Pi.
 
The fundamental question is how to get SIMH to talk to anything and then, once complete, how is that connectivity made manifest to internal simulated hardware.

You may well have to hack a bit on SIMH itself first, and then work on a device driver for RT-11.
 
I am pretty sure you can include some simh commands to associate a DEC device type with a host port, such as:

attach dz -V line=0,connect=/dev/ttyUSB0;9600-8n1

That should give me a DZ serial line unit (unless I'm oversimplifying).
 
SIMH is all written in the ‘C’ language.

SIMH supports user-written devices so, in theory, you could write your own device that occupies a number of words of I/O space. Each word could correspond to a particular fixed-point temperature or a group of 16 bits.

If you can link your BASIC-11 program to a piece of PDP-11 assembler code, then you can use this to read from a specific I/O word and transfer that to a BASIC-11 variable.

The chain of events is:

BASIC-11 calls a piece of PDP-11 machine code to read a specific I/O word.

SIMH detects the I/O access and determines that it is from your special device. SIMH calls your C device passing the I/O address.

You can now do whatever you want in the C language, the result of which returns a 16-bit word value back to SIMH.

SIMH resumes the emulation with the result of the machine code read being the value that your C code supplied.

The PDP-11 machine code stores that value where BASIC-11 can interrogate and use.

If course, such a device can never exist in the real QBUS world - unless you design your own QBUS hardware card!

Splitting your problem into two worlds (the emulated PDP-11 using SIMH and the PC/Pi world using C) means that the C world can handle the repetitive nature of the I/O interface and return a snapshot (on demand) from SIMH.

Dave
 
Can BASIC call arbitrary assembly? I thought they could only call SYS routines. Mind, I'm think of RSTS, dunno about RT-11.
 
Just checked the reference provided in post #3 and it contains everything you need to interface MACRO-11 code to BASIC-11.

However, probably a steep learning curve to start with!

In particular, Chapter 4 states:

1642594855619.png

Just what you want. Replace "laboratory equipment" by "home sensors" and you are good-to-go :)...

Dave
 
GreyHairedDECfan said:
I am pretty sure you can include some simh commands to associate a DEC device type with a host port, such as:

attach dz -V line=0,connect=/dev/ttyUSB0;9600-8n1

That should give me a DZ serial line unit (unless I'm oversimplifying).
Click to expand...

Using *NIX yes you can.

The issue you may fall into is throughput. The PDP-11 end has to process characters faster than the remote device can produce them (assuming no buffering or handshaking). It may be that the *NIX box can coordinate itself with remote device to support handshaking - this should prevent buffer overruns etc. If not, you may have an unreliable link - unless you can ensure that what the PDP-11 has received is a valid line before it is processed. In the case of ASCII characters that are not in a fixed format (or contain some form of checksum etc.) then this is not going to be practical.

Incidentally, just out of interest, I had a look at the BASIC-11 manuals and the details regarding adding MACRO-11 routines to BASIC-11 are all there. There is a learning curve (however)...

In order to add your assembler routines to BASIC-11 - you have to relink it and include the CALL statement and your assembled code.

Dave
 
daver2 said:
Using *NIX yes you can.

The issue you may fall into is throughput. The PDP-11 end has to process characters faster than the remote device can produce them (assuming no buffering or handshaking). It may be that the *NIX box can coordinate itself with remote device to support handshaking - this should prevent buffer overruns etc. If not, you may have an unreliable link - unless you can ensure that what the PDP-11 has received is a valid line before it is processed. In the case of ASCII characters that are not in a fixed format (or contain some form of checksum etc.) then this is not going to be practical.

Incidentally, just out of interest, I had a look at the BASIC-11 manuals and the details regarding adding MACRO-11 routines to BASIC-11 are all there. There is a learning curve (however)...

In order to add your assembler routines to BASIC-11 - you have to relink it and include the CALL statement and your assembled code.

Dave
Click to expand...
Yeah, I understand (now) how the data has to flow (thanks for the clarification in an earlier reply) and this is not something that I have sufficient time to devote to. Was just trying to do something useful with the OS and available languages (more than just Hello World or doing calculations).
 
>>> Was just trying to do something useful with the OS and available languages (more than just Hello World or doing calculations).

I know what you mean...

Much more fun.

Have those DLV11-J's arrived yet, or are they still in transit? We need to get you away with a real machine...

With a real machine you should be "good to go" with a DLV11-J serial card interfaced to something like a MODBUS slave. You can communicate with these very simply over an ASCII serial port using the standard TEXT driver - and they have support for detecting buffer overruns etc. See: https://en.wikipedia.org/wiki/Modbu...sed_on_7-_or_8-bit_asynchronous_serial_lines)

Dave
 
You must log in or register to reply here.
Back
Top