Hardcopy terminal emulators
1,140 views
Skip to first unread message
jon....@gmail.com
May 5, 2019, 9:50:53 PM5/5/19
to [PiDP-11]
Does anybody know of an equivalent to cool-retro-term that emulates a hardcopy terminal, such as an ASR-33 or DECWriter? I haven't really been able to find anything on Google, but it seems like it would be a cool accessory to a PiDP.
John Kennedy
May 5, 2019, 10:20:49 PM5/5/19
to [PiDP-11]
Do you want it to drive an actual printer?
Or just scroll up virtual paper on a display?
Sounds like it would make a nice iPad app :-)
Tom Lake
May 6, 2019, 1:07:47 AM5/6/19
to [PiDP-11]
I use PuTTY and choose a font called teletypewriter (Can't call it Teletype since that's a trademark).
I set the foreground to black and the background to a pale yellow as close to the canary paper color as I can get.
The effect is quite good.
Tom L
Lars Brinkhoff
May 6, 2019, 1:57:02 AM5/6/19
to [PiDP-11]
Jon wrote:
Does anybody know of an equivalent to cool-retro-term that emulates a hardcopy terminal, such as an ASR-33 or DECWriter? I haven't really been able to find anything on Google, but it seems like it would be a cool accessory to a PiDP.
I have long been advancing the idea that someone (not me!) should make a detailed 3D model and physically based fan-fold paper simulation.
I know someone who made an ARS33 emulator, but I think it's just in a ZIP file somewhere.
jon....@gmail.com
May 6, 2019, 3:22:47 AM5/6/19
to [PiDP-11]
I've used that as well, but having backspace erase characters kind of breaks the illusion of ink on paper. By the way, how was backspace generally dealt with? I know that sometimes the idiom of printing a /, followed by each deleted character, and another slash was used (e.g, backspace/ecapskcab/), and I've even run into one or two situations where I managed to accidentally elicit that response from a modern Linux desktop Linux system (I was doing something crazy, I forget exactly what). But I've had trouble getting that behavior deliberately from either ancient or modern systems. Setting TERM to a hardcopy terminal type on Linux, or the equivalent on ancient emulated systems, just results in characters being erased with backspace, most of the time. I've seen references to hardcopy terminals being able to physically backspace, and I can see uses for that in writing documents on a typewriter that require an unavailable character but can be composed from two available characters, but it seems utterly useless in a computer command line environment, so I'm surprised that a shell would echo back a backspace to a hardcopy terminal, as opposed to responding with something of the form mitsake/ekast/istake.
Jonathan Morton
May 6, 2019, 4:03:59 AM5/6/19
to jon....@gmail.com, [PiDP-11]
Physically, hardcopy terminals would respond to backspace characters by backspacing, ie. moving the carriage one column to the left. This very literal behaviour of the device is also why there were distinct CR and LF characters in ASCII, emitted in that order to begin a new line, since returning the carriage from the right edge of the page took longer than feeding the paper by one line.
There was usually not an erasure facility, though many electric typewriters did have one (which relied on memory of the current line of text, so the old character could be overstruck using the erase section of the ribbon). Instead backspacing was often used for strikeout, underline, double-strike for emboldening, and/or composing characters as you suggested.
Faster hardcopy printers included a buffer, and sometimes would neglect to physically move the carriage until just before printing a character, unless it was the result of an explicit carriage movement command (such as CR). This would have made printing double- or multi-strike characters faster. This applied to daisy-wheel printers and their derivatives. Dot-matrix printers, however, tended to build up a whole line in buffer before starting to print, and would often print alternate lines with the carriage moving in opposite directions, eliminating the time-consuming carriage-return movement. I forget whether these could be made to work well as hardcopy terminals by printing individual characters, but I suspect many could not.
Applications (and more particularly terminal libraries) designed for hardcopy terminals would respond to erasure keystrokes in various ways according to the convention of the time, much as they would convert a newline (LF) character into CR-LF. A simple way was just to emit a caret followed by an offset representation of the unprintable character; backspace would be ^H, erase-word would be ^W, erase-line was ^U. The use of strokes to indicate which characters were being erased is a more sophisticated approach which has since disappeared, since "glass TTYs" and their emulations are now ubiquitous.
- Jonathan Morton
There was usually not an erasure facility, though many electric typewriters did have one (which relied on memory of the current line of text, so the old character could be overstruck using the erase section of the ribbon). Instead backspacing was often used for strikeout, underline, double-strike for emboldening, and/or composing characters as you suggested.
Faster hardcopy printers included a buffer, and sometimes would neglect to physically move the carriage until just before printing a character, unless it was the result of an explicit carriage movement command (such as CR). This would have made printing double- or multi-strike characters faster. This applied to daisy-wheel printers and their derivatives. Dot-matrix printers, however, tended to build up a whole line in buffer before starting to print, and would often print alternate lines with the carriage moving in opposite directions, eliminating the time-consuming carriage-return movement. I forget whether these could be made to work well as hardcopy terminals by printing individual characters, but I suspect many could not.
Applications (and more particularly terminal libraries) designed for hardcopy terminals would respond to erasure keystrokes in various ways according to the convention of the time, much as they would convert a newline (LF) character into CR-LF. A simple way was just to emit a caret followed by an offset representation of the unprintable character; backspace would be ^H, erase-word would be ^W, erase-line was ^U. The use of strokes to indicate which characters were being erased is a more sophisticated approach which has since disappeared, since "glass TTYs" and their emulations are now ubiquitous.
- Jonathan Morton
Rene Richarz
May 6, 2019, 5:59:18 AM5/6/19
to [PiDP-11]
I remember very well the ARS-33 teletype I used initially on my first home built personal computer in 1977. Running the assembler with papertape source and teletype printout at home after work took hours and was extremely noisy. What a relief for my wife and neighbors when finally the tv display board was built and the software for it burned in ROM‘s! I‘m therefore not that much looking forward to a noisy and slow replica. The terminals using dot matrix printing on thermal paper were much nicer. The first needle printers (I remember having built one based on a heathkit kit) were a big step forward.
I still have a few program listings from these devices of my 1970‘s software. Well, they look quite nice but are sometimes difficult to read.
I still have a few program listings from these devices of my 1970‘s software. Well, they look quite nice but are sometimes difficult to read.
jon....@gmail.com
May 6, 2019, 6:06:47 AM5/6/19
to [PiDP-11]
On Monday, May 6, 2019 at 3:03:59 AM UTC-5, Jonathan Morton wrote:
Physically, hardcopy terminals would respond to backspace characters by backspacing, ie. moving the carriage one column to the left. This very literal behaviour of the device is also why there were distinct CR and LF characters in ASCII, emitted in that order to begin a new line, since returning the carriage from the right edge of the page took longer than feeding the paper by one line.
I knew that this was true as far as their behavior with the keys driving the print mechanism directly, but was confused as to how computers generally handled receiving a backspace when they knew they were speaking to a hardcopy terminal.
Applications (and more particularly terminal libraries) designed for hardcopy terminals would respond to erasure keystrokes in various ways according to the convention of the time, much as they would convert a newline (LF) character into CR-LF. A simple way was just to emit a caret followed by an offset representation of the unprintable character; backspace would be ^H, erase-word would be ^W, erase-line was ^U. The use of strokes to indicate which characters were being erased is a more sophisticated approach which has since disappeared, since "glass TTYs" and their emulations are now ubiquitous.
Actually, it hasn't disappeared, just been forgotten. I knew I had once gotten Ubuntu to use that particular erasure method, but forgot how. In trying to figure that out, I looked through stty(1) tonight and found the echoprt option. Bash and zsh seem to ignore it, but it turns out that dash, which is /bin/sh on Ubuntu, does honor the setting. I'm not sure if this is the method I had previously gotten the behavior by, as I recall the last time having been an accident that surprised me. But in any case, it seems that a hardcopy terminal could plausibly be used with a modern Linux system.
Anyways, the reason I had been confused was that I had been playing around with TOPS10 for the PDP10, and, despite being of appropriate vintage, it wasn't using slashes and backward printing for erasure with a hardcopy terminal type set. It turns out that that system seems to have a hardcoded assumption that the console is a video terminal, but non-console logins will respond appropriately to setting a hardcopy terminal type.
- Jonathan Morton
Lars Brinkhoff
May 6, 2019, 7:24:41 AM5/6/19
to [PiDP-11]
Jon Brase wrote:
Anyways, the reason I had been confused was that I had been playing around with TOPS10 for the PDP10, and, despite being of appropriate vintage, it wasn't using slashes and backward printing for erasure with a hardcopy terminal type set. It turns out that that system seems to have a hardcoded assumption that the console is a video terminal, but non-console logins will respond appropriately to setting a hardcopy terminal type.
ITS and its application programs will sometimes use \ and / to indicate delete characters. Or sometimes it will just print the deleted character.
If you set the type to a display terminal, some programs will backspace and erase. Other still do the hardcopy thing. It's a mixed bag of hacker shenanigans!
osuvman
May 6, 2019, 7:39:45 AM5/6/19
to [PiDP-11]
It still grates on my ears to hear people use backspace and delete interchangeably. In the old-time DEC OSes, backspace moved the printing position back one and the delete key, a different character sent by the keyboard, erased the previous character. I don't recall the classic DEC terminals having a backspace key, you had to use control-H to send that character.
Geoffrey McDermott
May 6, 2019, 10:14:14 AM5/6/19
to [PiDP-11]
Don't forget the LA-120(is that the correct designation?) dot matrix console printer.....it would move the print head off to the right so the operator could see what was printed.....the movement was automatic, and happened of no print or keyboard activity happened for a short time. It also automatically re-positioned the print head to the correct position when it continued printing.
Mark Matlock
May 6, 2019, 12:45:41 PM5/6/19
to Jonathan Morton, jon....@gmail.com, [PiDP-11]
Mark
Jonathon,
At the risk of hijacking this topic a bit....
One other use of the backspace overstrike capability of hard copy terminals was utilized in the programming language APL. APL used a custom keyboard and in the early days a typewriter ball that had a number of mathematic symbols in addition to capital letters and numbers. Many of the functions of APL were made by typing one symbol then backspace and typing a second symbol. The sequence was recognized to be a new function different from the two other symbols.
For example, matrix inversion was a symbol that combined a divide symbol and a “quad quote” symbol (see https://en.m.wikipedia.org/wiki/APL_syntax_and_symbols )
Trying to reproduce these symbols with glass TTYs was sometimes complicated and the VT220 Compose key had some function in that regard.
Anyone who wants to tinker with APL will find it installed on the RSX11M+ PiDP-11 installation. You should get a copy of the manual (see http://www.bitsavers.org/pdf/dec/pdp11/apl/ ) before trying it and probably choose the TT option for terminal type. This option substituted three letter codes for the APL characters. In it .DQ (Divide Quad) was the matrix inversion function.
When you get into APL-11 it is not obvious how to get out and that is done with )OFF
APL was known as a write only language (a bit like TECO) because of the cryptic nature of the code and its compact form. I once wrote a Conway’s life program with a single line of APL code for example.
It also supported the Tektronix 4010 so it might be interesting to see how that works. APL was originally designed to be a math nomenclature but was developed into a programming language by IBM. I used it first on an IBM 360, but later on a IBM 5100 desktop computer and also on a MCM 70 (see https://en.m.wikipedia.org/wiki/MCM/70 ) which was the first battery powered “laptop” complete with 4K or 8K RAM, virtual memory to cassette tape storage, using a 8008 microprocessor.
One key feature of APL was that your data, stored in variables was also stored together with your programs in a workspace. This concept later was a key function of spreadsheets.
For anyone who has an interest and is a good RSX programmer, a couple people from General Mills extended the APL-11 to utilize I/D space under RSX11M+, but I have not been able to get it to work. The first program overlay call causes a program crash from what I can determine. All the source code in Macro-11 for APL-11 is available and the I/D space extension is on one of the RSX SIG tapes that is also available in the PiDP11 files that are online.
Best,
Mark
oscarv
May 6, 2019, 1:42:14 PM5/6/19
to [PiDP-11]
Mark,
On Monday, May 6, 2019 at 6:45:41 PM UTC+2, Mark Matlock wrote:
On the MCM 70...
[...] and also on a MCM 70 (see https://en.m.wikipedia.org/wiki/MCM/70 )
Wikipedia says "Virtual memory was supported on all of the machines, although using cassettes for storage made it slow."
An 8008 with virtual memory on cassette tape - that was pioneering!
Kind regards,
Oscar.
Johnny Billquist
May 6, 2019, 3:36:51 PM5/6/19
to pid...@googlegroups.com
A couple of comments:
First of all, obviously, on a printing terminal, a backspace simply
moved the head backwards one character, allowing for overstriking the
previous character printed.
But this is the reaction when a backspace is being sent to the terminal.
What happens if you press a backspace depends on the OS. Most OSes back
then didn't assign any general meaning to a backspace entered. But you
are most likely thinking about, and actually meaning the delete
character/key, which sent a DEL.
And since obviously since a printing terminal cannot erase the
previously echoed character, deleting input characters must be handled
in some different way. Most systems would do it by some special
indicator, and then printing the characters deleted, for example like
you described it.
However, this requires that you then also understand what component of
the system actually does this. In Unix (and Linux) this is normally done
by the terminal driver, and it is controlled by a terminal setting which
you can examine/change with stty.
However, with modern shells, the terminal driver is no longer
responsible for processing of input. The shell instead reads one
character at a time, in order to also handle line editing and other
features. So, the shell then also handles the deletion of input
characters, and most shells have no handling for hardcopy terminals,
even if the system and terminal driver do.
The simplest way of testing in Unix would be to do the tests inside a:
cat > /dev/null
End with the EOF character (usually ^D) alone on a line.
While typing lines in the cat process, the lines read are purely handled
by the terminal driver, and the shell is not interfering.
The TERM variable is only used when programs explicitly check for it,
and is for understanding in more detail how to control the terminal. It
is not related to, or used by, the terminal driver.
Johnny
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/d4c962d5-0e4a-4e53-b11d-bd07b4289289%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d4c962d5-0e4a-4e53-b11d-bd07b4289289%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
First of all, obviously, on a printing terminal, a backspace simply
moved the head backwards one character, allowing for overstriking the
previous character printed.
But this is the reaction when a backspace is being sent to the terminal.
What happens if you press a backspace depends on the OS. Most OSes back
then didn't assign any general meaning to a backspace entered. But you
are most likely thinking about, and actually meaning the delete
character/key, which sent a DEL.
And since obviously since a printing terminal cannot erase the
previously echoed character, deleting input characters must be handled
in some different way. Most systems would do it by some special
indicator, and then printing the characters deleted, for example like
you described it.
However, this requires that you then also understand what component of
the system actually does this. In Unix (and Linux) this is normally done
by the terminal driver, and it is controlled by a terminal setting which
you can examine/change with stty.
However, with modern shells, the terminal driver is no longer
responsible for processing of input. The shell instead reads one
character at a time, in order to also handle line editing and other
features. So, the shell then also handles the deletion of input
characters, and most shells have no handling for hardcopy terminals,
even if the system and terminal driver do.
The simplest way of testing in Unix would be to do the tests inside a:
cat > /dev/null
End with the EOF character (usually ^D) alone on a line.
While typing lines in the cat process, the lines read are purely handled
by the terminal driver, and the shell is not interfering.
The TERM variable is only used when programs explicitly check for it,
and is for understanding in more detail how to control the terminal. It
is not related to, or used by, the terminal driver.
Johnny
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/d4c962d5-0e4a-4e53-b11d-bd07b4289289%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d4c962d5-0e4a-4e53-b11d-bd07b4289289%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
May 6, 2019, 3:41:41 PM5/6/19
to pid...@googlegroups.com
But as far as BS goes, if it was a key depended on which terminal you
had. A VT100 do have a Backspace key, clearly marked that way. VT200 and
newer terminals have a BS on F12 (I think it was), but only if you had
the terminal set to VT100 mode.
Johnny
Johnny Billquist
May 6, 2019, 3:43:45 PM5/6/19
to pid...@googlegroups.com
On 2019-05-06 16:14, Geoffrey McDermott wrote:
> Don't forget the LA-120(is that the correct designation?) dot matrix
> console printer.....it would move the print head off to the right so the
> operator could see what was printed.....the movement was automatic, and
> happened of no print or keyboard activity happened for a short time. It
> also automatically re-positioned the print head to the correct position
> when it continued printing.
Right. And another name for the LA120 was DECwriter III.
> Don't forget the LA-120(is that the correct designation?) dot matrix
> console printer.....it would move the print head off to the right so the
> operator could see what was printed.....the movement was automatic, and
> happened of no print or keyboard activity happened for a short time. It
> also automatically re-positioned the print head to the correct position
> when it continued printing.
Very common console terminal for all DEC systems in the 70s and 80s.
John Kennedy
May 6, 2019, 3:56:13 PM5/6/19
to [PiDP-11]
The original Microsoft Basic used underline characters as a backspace. You imagined it deleting the character. Crazy but it works.
Jason Vanick
May 6, 2019, 4:29:59 PM5/6/19
to [PiDP-11]
LA120's were still used in many car dealerships until very recently. In fact, I think there's still some out there, you absolutely can't kill them.
Before my time at ADP Dealer Services / CDK, they were running PDP 11's (and servicing them) and using them as terminal multiplexor nodes (I believe for x.25) with a custom OS, but I hooked up many a vt220 and la120 to Xyplex terminal servers when I first started working for them... oh the memories.
-J
dave...@gmail.com
May 6, 2019, 5:30:11 PM5/6/19
to [PiDP-11]
Hello Jon,
Your question is very timely. We're just a few weeks away from announcing a general-purpose ASCII teleprinter.
This device is a by-product of the Computer History Museum's IBM 1620 Jr. project. It is built from an IBM/Lexmark Wheelwriter 1000 typewriter. For a parts cost of less than $150 and a few hours of work [plus the cost of a WW 1000], you can have a printing terminal which can be connected to your PiDP-11/70 or any other mini/micro/replica computer of your choosing.
Our all-volunteer team will be making all of the design, instructions, software, etc. available free to the community.
We demonstrated a converted WW attached to our historic IBM 1620 replica [aka IBM 1620 Jr.] at last fall's VCF West. We received 1st place in Best In Show and 2nd place in Best Restoration. We've since re-written the firmware to not only emulate the IBM 1620's console typewriter but also a general-purpose ASCII terminal, selectable by hardware jumpers. There's one emulation slot available in the firmware if one wants to add a specific terminal like the DECWriter.
Here's our display board from VCF West 2019 which gives more information about the creation of the terminal:
https://www.dropbox.com/s/rotbrlj7x7gx1m8/VCF_2019_display.jpg?dl=0
Here are the step-by-step directions [with photos] for adapting the WW 1000:
https://github.com/IBM-1620/Junior/raw/master/docs/wheelwriter-adaptation-instructions.pdf
As soon as we're done testing the new firmware and a modification to our USB Interface board, I'll post a notice to this mail list.
Thanks,
Dave
Your question is very timely. We're just a few weeks away from announcing a general-purpose ASCII teleprinter.
This device is a by-product of the Computer History Museum's IBM 1620 Jr. project. It is built from an IBM/Lexmark Wheelwriter 1000 typewriter. For a parts cost of less than $150 and a few hours of work [plus the cost of a WW 1000], you can have a printing terminal which can be connected to your PiDP-11/70 or any other mini/micro/replica computer of your choosing.
Our all-volunteer team will be making all of the design, instructions, software, etc. available free to the community.
We demonstrated a converted WW attached to our historic IBM 1620 replica [aka IBM 1620 Jr.] at last fall's VCF West. We received 1st place in Best In Show and 2nd place in Best Restoration. We've since re-written the firmware to not only emulate the IBM 1620's console typewriter but also a general-purpose ASCII terminal, selectable by hardware jumpers. There's one emulation slot available in the firmware if one wants to add a specific terminal like the DECWriter.
Here's our display board from VCF West 2019 which gives more information about the creation of the terminal:
https://www.dropbox.com/s/rotbrlj7x7gx1m8/VCF_2019_display.jpg?dl=0
Here are the step-by-step directions [with photos] for adapting the WW 1000:
https://github.com/IBM-1620/Junior/raw/master/docs/wheelwriter-adaptation-instructions.pdf
As soon as we're done testing the new firmware and a modification to our USB Interface board, I'll post a notice to this mail list.
Thanks,
Dave
Mark Matlock
May 6, 2019, 5:54:46 PM5/6/19
to oscarv, [PiDP-11]
Oscar,
It was a bit slow, but when doing some telecomputing from home, it was better than tying up your home phone with 110 baud (or 300 baud high speed with later TI Silent writers). It was also not bad in the office compared to the IBM Selectric at its really strange 134.5 baud data rate.
The display was the biggest limitation with only a single line that made it hard to see the matrix you just inverted.
Best,
Best,
Mark
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/cbbe96b0-88c6-48e4-beef-45bea3b6d5ae%40googlegroups.com.
emt377
May 6, 2019, 9:30:49 PM5/6/19
to [PiDP-11]
You can tell the OS to not use backspaces for character deletion. On 11M, for example, SET /NOCRT=TI: (or is it =TT: on 11M? argh, brain-fade)
You're still at the mercy of code that outputs actual backspace, of course. Underlining and overstrike won't work right (so an Algol 60 pretty-printer might have problems :-))
Rene Richarz
May 7, 2019, 2:09:14 AM5/7/19
to [PiDP-11]
On Monday, May 6, 2019 at 11:30:11 PM UTC+2, dave...@gmail.com wrote:
Your question is very timely. We're just a few weeks away from announcing a general-purpose ASCII teleprinter.
This device is a by-product of the Computer History Museum's IBM 1620 Jr. project. It is built from an IBM/Lexmark Wheelwriter 1000 typewriter. For a parts cost of less than $150 and a few hours of work [plus the cost of a WW 1000], you can have a printing terminal which can be connected to your PiDP-11/70 or any other mini/micro/replica computer of your choosing.
Our all-volunteer team will be making all of the design, instructions, software, etc. available free to the community.
Very interesting! I'm looking forward to this interesting device.
Old memories are coming back. 1979 I had replaced the noisy ASR-33 on my home built 6502 computer with a IBM balltype typewriter. With my student budget I had purchased an old invoicing machine with a core memory based calculator and an IBM balltype typewriter. I do not remember the manufacturer of the device and cannot find anything on the Internet. All I remember is that it was enclosed in a nice desktop wooden case. I disposed of the non-functional calculator, but remember that it consisted of many boards and the core memory, even so it could do nothing more than adding numbers and printing them on the typewriter. I made the necessary interface and was driving the solenoids of the typewriter directly with the 6502. It was a very interesting little driver, because it was fully interrupt driven and could handle printing jobs in background while the user could do something unrelated in foreground.
I also wrote a simple text processor using 2 audio cassette tape drives, and wrote my complete thesis (Diss. ETH Zürich Nr. 6495) on the home built 6502 computer, printing it on the old IBM typewriter. The printouts of the typewriter did not have the quality requested by the ETH, because the typewriter had been heavily used and was worn out, but the ETH accepted the thesis because it was probably their first one written using a personal text processing system. Unfortunately I never made any pictures of the system with the typewriter, but one picture of the system itself has survived (see https://github.com/rricharz/R65). Oh dear, late 1970s hair style :-). Unfortunately the R65 software in that github repo does not include the Selectric driver, because it was soon thereafter replaced with different printer drivers.
jdmcmul...@gmail.com
May 7, 2019, 8:11:26 AM5/7/19
to [PiDP-11]
On Tuesday, 7 May 2019 02:30:49 UTC+1, emt377 wrote:
You can tell the OS to not use backspaces for character deletion. On 11M, for example, SET /NOCRT=TI: (or is it =TT: on 11M? argh, brain-fade)You're still at the mercy of code that outputs actual backspace, of course. Underlining and overstrike won't work right (so an Algol 60 pretty-printer might have problems :-))
If I remember rightly from the Algol-60 Lanuage Report, Algol 60
implementations only used underline as a mechanism to indicate Algol 60
keywords. Implementations could use other mechanisms to indicate
keywords.
Following is a quote from the Revised Report on
Algol 60 (URL
http://homepages.cs.ncl.ac.uk/cliff.jones/publications/OCRd/BBG63.pdf )
See section 2.2.2
"It should be particularly noted that throughout the reference language underlining [intypewritten copy; boldface type in printed copy – Ed.] is used for defining independent basic symbols (see sections 2.2.2 and 2.3). These are understood to have no relation to the individual letters of which they are composed. Within the present report[not including headings – Ed.] underlining [boldface – Ed.] will be used for no otherpurpose"
Thus,
it is allowed as an alternative to precede the keyword characters by a %
sign. This mechanism was/is used in the IMP-77 language (used by
University of Edinburgh: URL https://en.wikipedia.org/wiki/Edinburgh_IMP
)
As an aside I'm slowly working on re-implementing IMP-77 for use on the PiDP-11 using sources from (URL: http://history.dcs.ed.ac.uk/archive/languages/imp77/ )
I've "hacked" the Intel version to use heap (this is working on Window 10 + Linux)
Johnny Billquist
May 7, 2019, 4:59:24 PM5/7/19
to pid...@googlegroups.com
On 2019-05-07 03:30, 'emt377' via [PiDP-11] wrote:
> You can tell the OS to not use backspaces for character deletion. On
> 11M, for example, SET /NOCRT=TI: (or is it =TT: on 11M? argh, brain-fade)
TI: is your terminal. TT: is short for TT0:, which usually would be the
> You can tell the OS to not use backspaces for character deletion. On
> 11M, for example, SET /NOCRT=TI: (or is it =TT: on 11M? argh, brain-fade)
console.
And of course it's the same on RSX-11M-PLUS. I think it might be the
same on VMS as well.
emt377
May 7, 2019, 6:30:03 PM5/7/19
to [PiDP-11]
On KDF9, with papertape input produced on Flexowriters, the Algol 60 compilers represented the keywords as underlined words, easy because underscore did not move the carriage (so, the keys _ b _ e _ g _ i _ n produced the *begin* symbol), and underlined less-than gave you less-or-equal. Backspace was also employed; maybe not-equal was equal, backspace, slash (I forget).
On moving to a DEC-10 with the benighted ASCII character set, the actual compiler representation was altogether more primitive. But one could write a pretty-printer with LA36 output that looked like proper Algol.
emt377
May 7, 2019, 6:32:25 PM5/7/19
to [PiDP-11]
Ah, yes. I couldn't remember for the moment whether I was getting mental crosstalk from -11D/IAS.
Rene Richarz
May 8, 2019, 6:30:37 AM5/8/19
to [PiDP-11]
On Monday, May 6, 2019 at 6:45:41 PM UTC+2, Mark Matlock wrote:
APL was known as a write only language (a bit like TECO) because of the cryptic nature of the code and its compact form. I once wrote a Conway’s life program with a single line of APL code for example.It also supported the Tektronix 4010 so it might be interesting to see how that works. APL was originally designed to be a math nomenclature but was developed into a programming language by IBM. I used it first on an IBM 360, but later on a IBM 5100 desktop computer and also on a MCM 70 (see https://en.m.wikipedia.org/wiki/MCM/70 ) which was the first battery powered “laptop” complete with 4K or 8K RAM, virtual memory to cassette tape storage, using a 8008 microprocessor.
Hi Mark,
Many thanks for your interesting input.
I looked a bit into APL, and the possibility to make some nice plots using the Tektronix 4010 emulator. Probably a few of the still existing Tektronix 4014 plot files were made using APL. There are for example some nice APL examples at http://jmb.aplcloud.com/JBgames/TamS/AplExamples.pdf
But really, for somebody not used to APL and RSX11M+ there is an extremely steep learning curve, in fact too steep for me. I think a nice little youtube video or step by step writeup showing how to make a plot made by somebody who has experience with APL and RSX11M+ would be very nice.
Unfortunately, my own skills are related to Unix and C, and around 1980 we made our own tools for scientific plots. Unfortunately all that stuff is lost. I would certainly be interested to try it if somebody would write up the details for somebody with no experience such as me.
Rene
Mark Matlock
May 8, 2019, 7:36:08 AM5/8/19
to Rene Richarz, [PiDP-11]
> On May 8, 2019, at 5:30 AM, Rene Richarz <rene.r...@bluewin.ch> wrote:
>
> Hi Mark,
>
> Many thanks for your interesting input.
>
> I looked a bit into APL, and the possibility to make some nice plots using the Tektronix 4010 emulator. Probably a few of the still existing Tektronix 4014 plot files were made using APL. There are for example some nice APL examples at http://jmb.aplcloud.com/JBgames/TamS/AplExamples.pdf
>
> But really, for somebody not used to APL and RSX11M+ there is an extremely steep learning curve, in fact too steep for me. I think a nice little youtube video or step by step writeup showing how to make a plot made by somebody who has experience with APL and RSX11M+ would be very nice.
>
> Unfortunately, my own skills are related to Unix and C, and around 1980 we made our own tools for scientific plots. Unfortunately all that stuff is lost. I would certainly be interested to try it if somebody would write up the details for somebody with no experience such as me.
Thanks for the feedback, and I very much share the sentiment you communicated above, that we need to assume that many readers are new to the software. For myself I know very little about Unix, RSTS and only a bit about RT11 and very much appreciate the details of how to do things.
As I have time (pesky full time job) I’d like to continue to provide more “how to” pieces that are interesting (at least to me) information on things that are available in the SIG tapes and elsewhere.
I have loved the Tektronix 4010 project! I was thinking of putting a “how to” together about APL, because it was a language developed around the same time as FORTRAN but had very sophisticated capabilities. With your encouragement, I’ll definitely do that now and hopefully be able connect it with the Tektronix terminal project.
I do need to correct one thing in my earlier post, APL-11 supported three basic terminals a LA36 with the APL rom, a Tektronix 4013 (which must have had an APL keyboard and likely a character generation rom that made the APL symbols), and non-APL terminals with the two letter nemonics. Back in the day we had some HDS terminals that worked quite well with it.
Best,
Mark
osuvman
May 8, 2019, 7:45:30 AM5/8/19
to [PiDP-11]
On Tuesday, May 7, 2019 at 4:59:24 PM UTC-4, Johnny Billquist wrote:
TI: is your terminal. TT: is short for TT0:, which usually would be the
console.
And of course it's the same on RSX-11M-PLUS. I think it might be the
same on VMS as well.
Johnny
On VMS, device names follow the form XXcn:, but 'cn' defautls to 'A0' if omitted. Interactive logins assign the logical name TT to their current terminal, so using TT: as a filename will open on your current terminal and not TTA0:. The console on VMS is OPA0:.
Rene Richarz
May 8, 2019, 8:00:00 AM5/8/19
to [PiDP-11]
On Wednesday, May 8, 2019 at 1:36:08 PM UTC+2, Mark Matlock wrote:
> On May 8, 2019, at 5:30 AM, Rene Richarz <rene....@bluewin.ch> wrote:
I do need to correct one thing in my earlier post, APL-11 supported three basic terminals a LA36 with the APL rom, a Tektronix 4013 (which must have had an APL keyboard and likely a character generation rom that made the APL symbols), and non-APL terminals with the two letter nemonics. Back in the day we had some HDS terminals that worked quite well with it.
Some Tektronix terminals definitely supported a second character set. I have ignored that up to now, but as part of an APL project it could certainly be added. Other applications for the Tektronix terminals were just drawing the necessary fancy characters in software. Regarding the keyboard I have not found any document talking about special keyboards, But I have also not made an effort to find any such documentation.
Peter Willard
May 8, 2019, 9:21:11 AM5/8/19
to [PiDP-11]
Hmmm.... why do you do this?
Now I'm sitting here thinking about how I can create a new serial keyboard... share the serial feed with an old Okidata Microline 82 have... using a CD4066 to share the transmit (receive on the host) with printer and keyboard so I can emulate the old DEC LA36.
Rene Richarz
May 8, 2019, 9:21:38 AM5/8/19
to [PiDP-11]
On Wednesday, May 8, 2019 at 1:36:08 PM UTC+2, Mark Matlock wrote:> On May 8, 2019, at 5:30 AM, Rene Richarz <rene....@bluewin.ch> wrote:
I do need to correct one thing in my earlier post, APL-11 supported three basic terminals a LA36 with the APL rom, a Tektronix 4013 (which must have had an APL keyboard and likely a character generation rom that made the APL symbols)
I just found this announcement in Computerworld of 7. March, 1973:
So we need now a manual for this device to add in to the Tektronix emulator.
Rene Richarz
May 8, 2019, 9:51:27 AM5/8/19
to [PiDP-11]
The "APL" keyboard is in the Tektronix 4015 manual, see the switch and the LED.
Rene Richarz
May 8, 2019, 12:43:25 PM5/8/19
to [PiDP-11]
On Wednesday, May 8, 2019 at 1:36:08 PM UTC+2, Mark Matlock wrote:
I have loved the Tektronix 4010 project! I was thinking of putting a “how to” together about APL, because it was a language developed around the same time as FORTRAN but had very sophisticated capabilities. With your encouragement, I’ll definitely do that now and hopefully be able connect it with the Tektronix terminal project.
Mark,
I have studied the Tektronix 4015 manual. You can find it at http://bitsavers.informatik.uni-stuttgart.de/pdf/tektronix/401x/
The relevant APL pages are 2-4 and B-1. If you want me to emulate the 4015 with APL code chart and keyboard, please let me know. If that's the case, I will open an issue on Github in the tek4010 repo, and we can talk there about technical details, which are probably not interesting for most of the PiDP-11 users. Emulating this with the unicode APL385 true type font and a code translation table should be trivial.
Rene
Johnny Billquist
May 8, 2019, 3:47:18 PM5/8/19
to pid...@googlegroups.com
also do it in some places.
However, I had totally missed (or forgotten) that you get a logical name
for TT pointing to your terminal.
In RSX, TI: is a device on its own, however, it's a sortof special
device that maps to some other device for each task. Similar to how
/dev/tty is in Unix.
Neil Higgins
May 8, 2019, 6:39:30 PM5/8/19
to [PiDP-11]
Seeing Pete Willard’s comment about an Okidata Microline 82 printer reminded me: I bought an Okidata Microline 80 for my 11/03 (actually a Heathkit H11 running RT-11). It was a dot matrix impact printer with a conventional typewriter ribbon. Incredibly noisy, with a blood curdling screech. If you loaded the ribbon the wrong way, It would eventually bind, stretch, and spring out of the printer.
It came with a Centronix (parallel) interface, and I bought (an outrageously expensive) serial adapter which contained not much more than an 8085 processor. The interesting thing about this was the flow control. You sent it a “packet” of printable characters and if the printer was not ready, it NAKed the whole packet, which you then had to re-send, sometimes multiple times (depending on the baud rate).
To get it working like any ol’ printer in RT-11 required a custom application to support the packet “protocol”, which I duly wrote in MACRO-11. I could have transformed this into a printer driver, but I never got around to that; however I did add limited support for runoff-style markup.
Those were the days.
It came with a Centronix (parallel) interface, and I bought (an outrageously expensive) serial adapter which contained not much more than an 8085 processor. The interesting thing about this was the flow control. You sent it a “packet” of printable characters and if the printer was not ready, it NAKed the whole packet, which you then had to re-send, sometimes multiple times (depending on the baud rate).
To get it working like any ol’ printer in RT-11 required a custom application to support the packet “protocol”, which I duly wrote in MACRO-11. I could have transformed this into a printer driver, but I never got around to that; however I did add limited support for runoff-style markup.
Those were the days.
Mark Matlock
May 9, 2019, 6:49:58 AM5/9/19
to [PiDP-11]
On May 8, 2019, at 11:43 AM, Rene Richarz wrote:
I have studied the Tektronix 4015 manual. You can find it at http://bitsavers.informatik.uni-stuttgart.de/pdf/tektronix/401x/
The relevant APL pages are 2-4 and B-1. If you want me to emulate the 4015 with APL code chart and keyboard, please let me know. If that's the case, I will open an issue on Github in the tek4010 repo, and we can talk there about technical details, which are probably not interesting for most of the PiDP-11 users. Emulating this with the unicode APL385 true type font and a code translation table should be trivial.
Rene,
M_10 10 .RO 100 ? 100
The _ is the assignment arrow, .RO is the greek rho that dimensions a variable, and ? Is a random number function. 100 ? 100 will produce 1 to 100 in random order and that will be dimension 10 by 10 and stored in M. Now we can display M
M_M-50
M_M%100
M
-0.41 0.37 -0.27 -0.17 -0.23 -0.06 -0.28 0.43 -0.02 0.25
-0.31 0.39 -0.25 -0.24 -0.15 0.33 -0.48 0 0.32 -0.37
0.45 -0.20 0.21 0.03 0.12 0.34 0.20 0.49 -0.14 -0.39
0.11 -0.08 0.29 -0.16 -0.09 0.42 0.22 0.17 0.05 -0.40
0.28 0.35 0.23 0.08 0.14 0.09 0.47 -0.49 -0.21 0.36
-0.29 0.07 -0.35 -0.45 0.13 -0.01 0.46 0.26 0.06 -0.18
-0.07 -0.43 -0.10 -0.38 0.44 0.15 0.04 -0.03 0.41 0.40
-0.26 -0.30 -0.04 -0.11 0.50 0.30 0.38 0.31 0.01 0.27
I would definitely be interested in a 4015 with APL characters and would be glad to collaborate. I will connect with you on GitHub. Also, thanks for the APL examples link. That helps to refresh my memory of APL syntax. It would really be great not to have to use the TT interface for APL-11.
Thanks,
Mark
Anyone interested in APL on the PDP-11:
The RSX11M+ (Frodo) distribution has APL-11 installed and working if you want to take a quick look. For the really interested in APL-11, the DU1 disk image on RSX11M.com has the source code (DECUS 11-SP-25) in DU1:[201,50] That contains the Macro-11 source code for APL-11. In that directory is APL11SUP.DOC, which describes the operation of the APL-11 interpreter in fantastic detail. The DU1:[201,200] is an area to build APL-11 in different flavors that use FPP, FIS or EIS and do either single precision floating or double precision math. In directory DU1:[6,17] is a copy of APLID.DOC and the modified source to build APL-11 as an I/D with FCSFSL to achieve a workspace size as close to 64KB as possible by Bob Awde that he presented at the Spring 1985 DECUS. This is something I have been trying to get working under RSX11M+ V4.6 unsuccessfully at least so far.
Before you do try to use APL-11, it would be helpful to download the APL-11 Programmers Reference manual at:
You should print pages 1-3 through 1-9 and have them handy. In those pages is an explanation of the two letter symbols that are used with a plain terminal to replace the APL special characters. Below is a quick example of its use.
To access it in RSX (PiDP11 switches set to 1):
>APL
TERMINAL..H
GIVE THE APPROPRIATE RESPONSE FOR YOUR TERMINAL
RESPONSE YOUR TERMINAL
LA36 LA36 WITH APL CHARACTER SET OPTION
4013 TEKTRONIX 4013
TT ANY TERMINAL NOT HAVING APL FONT
TERMINAL..TT
WELCOME TO APL-11 V02-03
CLEAR WS
.BXWA
31760
TERMINAL..H
GIVE THE APPROPRIATE RESPONSE FOR YOUR TERMINAL
RESPONSE YOUR TERMINAL
LA36 LA36 WITH APL CHARACTER SET OPTION
4013 TEKTRONIX 4013
TT ANY TERMINAL NOT HAVING APL FONT
TERMINAL..TT
WELCOME TO APL-11 V02-03
CLEAR WS
.BXWA
31760
.BX is the symbol for the APL quad symbol, a square box. WA is Workspace Available so at this point we 31760 bytes available.
M_10 10 .RO 100 ? 100
The _ is the assignment arrow, .RO is the greek rho that dimensions a variable, and ? Is a random number function. 100 ? 100 will produce 1 to 100 in random order and that will be dimension 10 by 10 and stored in M. Now we can display M
M
9 87 23 33 27 44 22 93 48 75
19 89 25 26 35 83 2 50 82 13
95 30 71 53 62 84 70 99 36 11
61 42 79 34 41 92 72 67 55 10
78 85 73 58 64 59 97 1 29 86
21 57 15 5 63 49 96 76 56 32
43 7 40 12 94 65 54 47 91 90
24 20 46 39 100 80 88 81 51 77
18 74 31 4 16 14 66 45 3 52
98 28 38 69 37 68 60 6 8 17
9 87 23 33 27 44 22 93 48 75
19 89 25 26 35 83 2 50 82 13
95 30 71 53 62 84 70 99 36 11
61 42 79 34 41 92 72 67 55 10
78 85 73 58 64 59 97 1 29 86
21 57 15 5 63 49 96 76 56 32
43 7 40 12 94 65 54 47 91 90
24 20 46 39 100 80 88 81 51 77
18 74 31 4 16 14 66 45 3 52
98 28 38 69 37 68 60 6 8 17
M_M-50
Here we subtract 50 from every element of matrix M and store it back into M
M_M%100
Here we divide every element of M by 100. Note that % is being used to represent the divide symbol (not a /). Now M looks like this:
M
-0.41 0.37 -0.27 -0.17 -0.23 -0.06 -0.28 0.43 -0.02 0.25
-0.31 0.39 -0.25 -0.24 -0.15 0.33 -0.48 0 0.32 -0.37
0.45 -0.20 0.21 0.03 0.12 0.34 0.20 0.49 -0.14 -0.39
0.11 -0.08 0.29 -0.16 -0.09 0.42 0.22 0.17 0.05 -0.40
0.28 0.35 0.23 0.08 0.14 0.09 0.47 -0.49 -0.21 0.36
-0.29 0.07 -0.35 -0.45 0.13 -0.01 0.46 0.26 0.06 -0.18
-0.07 -0.43 -0.10 -0.38 0.44 0.15 0.04 -0.03 0.41 0.40
-0.26 -0.30 -0.04 -0.11 0.50 0.30 0.38 0.31 0.01 0.27
-0.32 0.24 -0.19 -0.46 -0.34 -0.36 0.16 -0.05 -0.47 0.02
0.48 -0.22 -0.12 0.19 -0.13 0.18 0.10 -0.44 -0.42 -0.33
0.48 -0.22 -0.12 0.19 -0.13 0.18 0.10 -0.44 -0.42 -0.33
N_.DQM
The .DQ stands for Divide Quad and in APL characters is a box with a divide symbol backspaced and typed inside it. It does a matrix inversion that then we store in N
+/M
-0.39 -0.76 1.11 0.53 1.3 -0.3 0.43 1.06 -1.77 -0.71
The / is not divide but compress +/ adds all elements along a dimension together like the mathematic symbol Sigma. Here the rows were summed and displayed as a vector. To designate a row.
M[1;]
-0.41 0.37 -0.27 -0.17 -0.23 -0.06 -0.28 0.43 -0.02 0.25
To sum all elements in the matrix, just apply +/ twice. You could multiply all elements with #/ (in APL * is exponentiate and there is a x symbol different from X so with the TT substitution # is multiply)
+/+/M
0.5
)VARS Displays all variables that have been define
)FNS Displays any functions that have been defined
)SAVE NAME Save the Workspace to NAME (as NAME.APC )
)OFF Exits APL. Also ^Z works too.
Rene Richarz
May 9, 2019, 10:03:34 AM5/9/19
to [PiDP-11]
Mark,
I have opened an issue in the tek4010 repo. I have basically implemented the APL codes, but not yet uploaded the modified version. But there is a sceen dump of the tek display with APL mode there, and a code snipped showing the tek to unicode conversion. I think that a few of the unicodes are wrong.
If you log in in github, and watch the repo or the issue, you can get all comments in this issue over email and you can make your comments there.
Once the code set looks reasonable, I will upload the modified version and we can test it with APL on the PiDP-11.
Rene
Mark Matlock
May 9, 2019, 11:05:59 PM5/9/19
to [PiDP-11]
Rene,
I've logged into your github and left comments there.
You are making fantastic progress with the APL character set. I look forward to using real APL symbols instead of the two letter nemonics!
Thanks,
Mark
Mark Matlock
May 10, 2019, 6:06:32 AM5/10/19
to Rene Richarz, [PiDP-11]
On May 8, 2019, at 11:43 AM, Rene Richarz <rene.r...@bluewin.ch> wrote:
I have studied the Tektronix 4015 manual. You can find it at http://bitsavers.informatik.uni-stuttgart.de/pdf/tektronix/401x/
The relevant APL pages are 2-4 and B-1. If you want me to emulate the 4015 with APL code chart and keyboard, please let me know. If that's the case, I will open an issue on Github in the tek4010 repo, and we can talk there about technical details, which are probably not interesting for most of the PiDP-11 users. Emulating this with the unicode APL385 true type font and a code translation table should be trivial.
Rene,
I would definitely be interested in a 4015 with APL characters and would be glad to collaborate. I connect with you on GitHub. Also, thanks for the APL examples link. That helps to refresh my memory of APL syntax. It would really be great not to have to use the TT interface for APL-11.
Thanks,
Mark
Anyone interested in APL on the PDP-11:
The RSX11M+ (Frodo) distribution has APL-11 installed and working if you or anyone wants to take a quick look. For the really interested in APL-11, the DU1 disk image on RSX11M.com has (DECUS 11-SP-25) in DU1:[201,50] That contains the Macro-11 source code for APL-11. DU1:[201,200] is an area to build it. It comes in different flavors that use FPP or EIS and do either single precision floating or double.
Before you do try to use it, it would be helpful to download the APL-11 Programmers Reference manual at:
Print pages 1-3 through 1-9. In those pages is an explanation of the two letter symbols that are used with a plain terminal to replace the APL characters. Below is a quick example of its use.
Terry Kennedy
May 31, 2019, 11:30:01 PM5/31/19
to [PiDP-11]
On Sunday, May 5, 2019 at 9:50:53 PM UTC-4, jon....@gmail.com wrote:
Does anybody know of an equivalent to cool-retro-term that emulates a hardcopy terminal, such as an ASR-33 or DECWriter? I haven't really been able to find anything on Google, but it seems like it would be a cool accessory to a PiDP.
I've been off-net in the Mojave Desert for over a month, so pardon the delayed response...
The 33-series Teletype units (ASR33/KSR33) didn't do backspace - the carriage could only move forward by one position or do a carriage return (which was damped by a plunger going into a cup to keep things from crashing). It also called its delete key "rub out" (0127). To complicate matters, there were a large variety of font drums and since the 33s used for computers were often off-lease units from other applications, there was no guarantee that any two units had the same character set.
Complicating matters, some of these terminals were operated in half-duplex (AKA "local echo") mode, so the host did not have control of what was echoed. In addition to correcting typos, this also had an impact on things like entering passwords. Some systems would do a carriage return (and no linefeed) and repeatedly over-print the typed password with a pattern to make it (hopefully) unreadable. Some systems allowed control characters (which didn't print anything) in passwords.
Some systems used a printing backarrow character (sort of like "<-") to indicate that the previous character was deleted by the user pressing the "rub out" key - since it didn't actually print a character (although it did cycle the font drum and would punch all holes in paper tape if the punch was enabled). So if you typed "PRIMT" when you meant "PRINT", you'd see "PRIMT<-<-NT". That was OK if you were only backing up a character or two, but quickly became unmanageable for larger amounts. Some systems would print a [back]slash and the first character to be deleted for the first rub out, then any additional characters for further rub outs, then a closing [back]slash and the new character for the first non-rub out character, which would look like "PRIMT\TM\NT". Since this depended on the terminal being able to print something other than the character the user pressed, it didn't work for half-duplex terminals.
So you ended up with a large variety of possible behavior, complicated further if the system supported terminals with different character sets (in some 33 font drums the "<-" was in a different position or didn't exist at all). And of course, no 2 host systems would do the same thing, unless they were run by the same computer center (and not even then, in some cases).
emt377
Jun 1, 2019, 10:13:41 AM6/1/19
to [PiDP-11]
(I've used most of those systems!)
But much of the behavior specified is in the host OS, not in the terminal emulator. With one exception, emulation of a teletype seems to me to consist of not using many of the capabilities you otherwise have (like cursor movement); you'd also need to tell the OS that you had a hardcopy terminal.
The exception is arbitrary overprinting, of course; generally not possible on a CRT-based character terminal.
Terry Kennedy
Jun 1, 2019, 2:03:35 PM6/1/19
to [PiDP-11]
On Saturday, June 1, 2019 at 10:13:41 AM UTC-4, emt377 wrote:
(I've used most of those systems!)But much of the behavior specified is in the host OS, not in the terminal emulator. With one exception, emulation of a teletype seems to me to consist of not using many of the capabilities you otherwise have (like cursor movement); you'd also need to tell the OS that you had a hardcopy terminal.
Sure. But (for example) you can't have an "Model 33 terminal emulator" unless you emulate all the possible font drums (there are over 50, but not all of them are useful for computer terminals).
Paul Birkel
Jun 1, 2019, 2:33:57 PM6/1/19
to dave...@gmail.com, [PiDP-11]
Great news Dave. Very much looking forward to the CHM finalizing and releasing this work :->!
See: https://oshpark.com/shared_projects/BBjLtMnE ($52.25 for three)
Is the “modification to our USB Interface board” going to result in new Gerbers?
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/2c7b078f-163f-483b-9d5b-eef24bffbcea%40googlegroups.com.
Stephen Casner
Jun 1, 2019, 3:16:48 PM6/1/19
to Paul Birkel, dave...@gmail.com, [PiDP-11]
On Sat, 1 Jun 2019, Paul Birkel wrote:
> Great news Dave. Very much looking forward to the CHM finalizing
> and releasing this work :->!
>
> See: https://oshpark.com/shared_projects/BBjLtMnE ($52.25 for three)
>
> Is the "modification to our USB Interface board" going to result in new Gerbers?
Sorry, I forgot to click "Start Sharing" on the OSHPark project for
> Great news Dave. Very much looking forward to the CHM finalizing
> and releasing this work :->!
>
> See: https://oshpark.com/shared_projects/BBjLtMnE ($52.25 for three)
>
> Is the "modification to our USB Interface board" going to result in new Gerbers?
the new Rev 1.7 of the board.
See: https://oshpark.com/shared_projects/ZLEsAzsQ
Caution: I have high confidence that this new version will work correctly,
but I have not built one yet because we are waiting for new FFC cables
with ZIF terminations that will allow us to avoid having to replace
the keyboard ZIF connectors on the typewriter's logic board with
latching connectors to fit the only cables we were able to find
previously.
I will also need to update the typewriter modification instructions on
GitHub to cover the changes.
I have in mind a possible Rev 1.8 in the future as well. We are using
the Wheelwriter 1000, but there are other models in the Wheelwriter
line that have some more function keys that are connected to a 16th
column line in the keyboard matrix that is not present in the WW 1000
and therefore not connected on our current USB Interface Board. We
might be able to extend the design to work with those models as well.
-- Steve
Tom Lake
Jun 1, 2019, 8:30:43 PM6/1/19
to pid...@googlegroups.com
As soon as we're done testing the new firmware and a modification to our USB Interface board, I'll post a notice to this mail list.
Thanks,
Dave
Does the modification to the USB board require different parts than the ones on the current BOM? I ordered the USB interface boards (version 1.7) already but if the differences are great, I'll hold off on adding the parts to it until new version 1.8 boards are available. Also, does the Teensy allow a USB to serial converter? I'd really like an RS-232 interface rather than the USB.
I'm excited to try get one of these to work!
Tom L
Stephen Casner
Jun 1, 2019, 8:59:08 PM6/1/19
to Tom Lake, [PiDP-11]
On Sat, 1 Jun 2019, Tom Lake wrote:
> Does the modification to the USB board require different parts than the
> ones on the current BOM? I ordered the USB interface boards already but
> Does the modification to the USB board require different parts than the
> I'll hold off on adding the parts to it until new boards are available.
> Also, does the Teensy allow a USB to serial converter? I'd really like an
> RS-232 interface rather than the USB.
Yes, we replaced the two 7404 hex inverters with a 74LS540 octal
> RS-232 interface rather than the USB.
inverting buffer because we found a problem with the hex inverters
activating all of the keyboard row sense lines at the same time while
the Teensy was downloading new firmware. This is not a valid
situation for a real keyboard, and it caused the typewriter to do
random carriage motions and printing and may have been the cause of a
failure on a logic board.
I devised a fix for this problem by adding pulldown resistors to the
Rev 1.6 boards. If you have already ordered those boards, I can
provide the details and you can do the same fix.
-- Steve
Tom Lake
Jun 1, 2019, 10:12:32 PM6/1/19
to pid...@googlegroups.com
I devised a fix for this problem by adding pulldown resistors to the
Rev 1.6 boards. If you have already ordered those boards, I can
provide the details and you can do the same fix.
-- Steve
I just checked OSH Park again. The Rev. 1.7 board I ordered uses the 74LS540 so I won't be needing the resistors.
Thanks, Steve!
Tom L
Stephen Casner
Jun 1, 2019, 10:47:06 PM6/1/19
to Tom Lake, [PiDP-11]
No, the 1.7 board uses the 74LS540, which is the cleaner solution. The pull down resistors were added to our existing 1.6 boards to work around the problem.
-- Steve
I devised a fix for this problem by adding pulldown resistors to the
Rev 1.6 boards. If you have already ordered those boards, I can
provide the details and you can do the same fix.
-- Steve
So the Rev. 1.7 board needs the same resistors? If so, please post the fix. Thanks!Tom L
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6a348a20-27cb-4026-8e0e-13f50bfaac2b%40googlegroups.com.
Stephen Casner
Jun 5, 2019, 7:06:20 PM6/5/19
to Tom Lake, [PiDP-11]
On Sat, 1 Jun 2019, Tom Lake wrote:
> Also, does the Teensy allow a USB to serial converter? I'd really
> like an RS-232 interface rather than the USB.
I neglected to answer this part. The USB Interface Board design
> like an RS-232 interface rather than the USB.
includes bringing out the Teensy pins assigned to UART RX and TX to
separate pads where you could put a 3-pin header to get RX, TX and GND
off to an RS-232 converter. These signals are 3.3V logic level, not
RS-232, so you'd need a level converter like the ones suggested for
use with the Pi if you need real RS-232.
The design currently does not have a +3.3V or +5V pad next to the RX,
TX and GND pads. Would that help? Which voltage would be preferred?
Also, the firmware as currently written does not drive the UART
function, but that could be added.
-- Steve
p.s. I now have all the parts and ZIF cables, so I will be building
and testing the Rev 1.7 boards that I have.
Tom Lake
Jun 5, 2019, 11:35:53 PM6/5/19
to [PiDP-11]
While I can't speak for anyone but for myself, but I'd prefer 3.3v. I'd hook up a MAX3232 to it which seems to work fine when using
real RS-232 equipment. When I look at my OSH Park order, the picture attached to it shows a rev 1.7 board so I hope that's what I'll be getting!
Tom L
Paul Birkel
Jun 6, 2019, 4:26:25 AM6/6/19
to Tom Lake, [PiDP-11]
I’d personally prefer +5v; less pumping to get good output swing :->.
I see that all of the ones listed at Mouser (https://www.mouser.com/Semiconductors/Interface-ICs/RS-232-Interface-IC/_/N-45lx1?Keyword=MAX3232&FS=True) seem to be supply voltage-tolerant anywhere between 3 and 5.5v.
And they do carry the PDIP “old school package”. And any other logic that I’d employ on a daughterboard would be “old school” 5v.
Please do enhance the firmware to support a UART!
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6b0be9d1-a299-4278-a477-e8ca4a9af25f%40googlegroups.com.
Tom Lake
Jun 6, 2019, 5:00:53 PM6/6/19
to [PiDP-11]
So it wouldn't be possible to plug a USB to RS-232 converter like the TrendNet TU-S9 or FTDI in and have it work? If I can get away without having to solder, I usually take that option.
On Wednesday, June 5, 2019 at 7:06:20 PM UTC-4, Stephen Casner wrote:
Stephen Casner
Jun 6, 2019, 6:32:38 PM6/6/19
to Tom Lake, [PiDP-11]
On Thu, 6 Jun 2019, Tom Lake wrote:
> So it wouldn't be possible to plug a USB to RS-232 converter like the
> TrendNet TU-S9 or FTDI in and have it work? If I can get away without
> having to solder, I usually take that option.
No, there is no USB A socket where you could plug in the TU-S9. The
> So it wouldn't be possible to plug a USB to RS-232 converter like the
> TrendNet TU-S9 or FTDI in and have it work? If I can get away without
> having to solder, I usually take that option.
Teensy has a micro-USB connector that you connect to your computer
with a USB A to micro-USB cable, and that appears as a serial device
on your computer for purposes of downloading firmware to the Teensy
and, with our firmware running, to use the typewriter as a terminal on
the computer. That's how we use it for the IBM 1620 Jr. project with
the USB cable plugged into the Raspberry Pi that runs the 1620
simulation.
Instead, you would use a product like this:
http://www.nulsom.com/datasheet/NS-RS232_en.pdf
This may not be the best or most appropriate one, but something like
that. It would connect with 4 wires to the USB Interface Board and
presents a DE9 serial connector. The 4 wires could be directly
soldered at both ends or you could put in 0.1 inch pitch headers and
sockets at both ends.
I'm working on a longer message to be sent shortly...
-- Steve
Stephen Casner
Jun 6, 2019, 7:44:17 PM6/6/19
to Tom Lake, Paul Birkel, [PiDP-11], dave...@gmail.com
I have now completed testing of the Rev 1.7 USB Interface Board for
adapting the Wheelwriter 1000. My statement of high confidence that
it would work correctly has been confirmed.
The design is here: https://oshpark.com/shared_projects/ZLEsAzsQ
I still need to update the document on GitHub describing the assembly
and modification of the Wheelwriter to include the BOM for Rev 1.7.
The only difference in the BOM resulting from the design change is to
replace two 7404 hex inverters with one 74LS540 octal inverting
buffer.
However, the bigger change is that we are now able to use flat flex
cables (FFC) with ZIF terminations rather than latching connectors to
go between the USB Interface Board and the typewriter's logic board.
That avoids the somewhat difficult step of harvesting the
low-insertion-force (LIF) keyboard connectors from the typewriter's
logic board to reuse on the USB Interface Board and replacing them
with latching connectors. That approach would still work fine with
the Rev 1.7 boards and uses connectors and cables that are readily
available from DigiKey, but then the typewriter can't be restored to
its original configuration without the USB Interface Board installed
for testing or repair.
We went with the connector replacement approach initially because
buying the same LIF connectors that are present on the typewriter's
logic board (TE Connectivity 6-520315-5) from DigiKey would require
ordering 2160 of them and waiting 16 weeks. However, we have now
found that they are available from Heilind Electronics in small
quantities. They have about 2000 in stock, and I expect they are sold
very infrequently, but I bought 50 of them to cover our project needs
and to have some on hand in case future needs might arise.
The FFC cables with 15 conductors on 0.1 inch (2.54 mm) spacing are
also considered ancient technology. The ones with latching connectors
attached are available as standard products from DigiKey, but not with
ZIF terminations (basically just exposed conductors at the end).
There are vendors who would gladly make them to order, but we'd have
to buy thousands of them. However, I found one vendor, Wavelink LLC,
who agreed to make a small order for us and said they are willing to
make more for others.
The TE Connectivity 6-520315-5 connector mounts vertically on the PCB.
The USB Interface Board needs vertical connectors on the input side
but right-angle connectors on the output side. There is a right-angle
variant, 6-520314-5, but there are none in stock anywhere. So instead
the pins of the vertical connector can be bent 90 degrees to install
it as a right-angle connector. In fact, looking at the connector
design diagrams, we can see that is exactly what the manufacturer
did. But the right-angle version had two tabs sticking out the back
side to keep the connector from tilting away from the board as the
cable is inserted. Since we don't have those tabs, the connector can
be held in place by gluing the body of the connector to the PCB.
The attached photo shows the USB Interface Board with these connectors
and ZIF cables in place.
For any of you who are intested in replicating this Wheelwriter
adaptation but are not antsy to jump on it right away, I suggest that
you wait for the Rev 1.8 design that I will have done soon. It
includes wiring for the additional keyboard column scan line that is
present on some other Wheelwriter models, but not the 1000, to allow
for extending the adaptation for those other models. I've also
removed the solder mask to expose the underlying board surface in the
area under where LIF connectors modified for right-angle entry are
to be glued, for more secure adhesion. And I will extend the optional
3-pin headers for I2C and UART connections to add a 4th pin for
power. My plan is to put 3.3V on the I2C header and 5V on the UART
header. This is to allow connecting a TTL-to-RS232 serial converter
such as:
http://www.nulsom.com/datasheet/NS-RS232_en.pdf
I see several similar devices but the order of the VCC, GND, RX and TX
pins varies among the devices, so there probably would not be a 1:1
mapping between the 4-pin header on the USB Interface Board and a
4-pin header on the RS232 converter. I have seen cables with a 4-pin
socket on one end and 4 separate single-pin sockets on the other end
which would allow reordering the wires as needed.
With a Rev 1.6 or Rev 1.7 board you can still use an RS232 converter
but you would need to make a connection to power on the underside of
the board.
-- Steve
adapting the Wheelwriter 1000. My statement of high confidence that
it would work correctly has been confirmed.
The design is here: https://oshpark.com/shared_projects/ZLEsAzsQ
I still need to update the document on GitHub describing the assembly
and modification of the Wheelwriter to include the BOM for Rev 1.7.
The only difference in the BOM resulting from the design change is to
replace two 7404 hex inverters with one 74LS540 octal inverting
buffer.
However, the bigger change is that we are now able to use flat flex
cables (FFC) with ZIF terminations rather than latching connectors to
go between the USB Interface Board and the typewriter's logic board.
That avoids the somewhat difficult step of harvesting the
low-insertion-force (LIF) keyboard connectors from the typewriter's
logic board to reuse on the USB Interface Board and replacing them
with latching connectors. That approach would still work fine with
the Rev 1.7 boards and uses connectors and cables that are readily
available from DigiKey, but then the typewriter can't be restored to
its original configuration without the USB Interface Board installed
for testing or repair.
We went with the connector replacement approach initially because
buying the same LIF connectors that are present on the typewriter's
logic board (TE Connectivity 6-520315-5) from DigiKey would require
ordering 2160 of them and waiting 16 weeks. However, we have now
found that they are available from Heilind Electronics in small
quantities. They have about 2000 in stock, and I expect they are sold
very infrequently, but I bought 50 of them to cover our project needs
and to have some on hand in case future needs might arise.
The FFC cables with 15 conductors on 0.1 inch (2.54 mm) spacing are
also considered ancient technology. The ones with latching connectors
attached are available as standard products from DigiKey, but not with
ZIF terminations (basically just exposed conductors at the end).
There are vendors who would gladly make them to order, but we'd have
to buy thousands of them. However, I found one vendor, Wavelink LLC,
who agreed to make a small order for us and said they are willing to
make more for others.
The TE Connectivity 6-520315-5 connector mounts vertically on the PCB.
The USB Interface Board needs vertical connectors on the input side
but right-angle connectors on the output side. There is a right-angle
variant, 6-520314-5, but there are none in stock anywhere. So instead
the pins of the vertical connector can be bent 90 degrees to install
it as a right-angle connector. In fact, looking at the connector
design diagrams, we can see that is exactly what the manufacturer
did. But the right-angle version had two tabs sticking out the back
side to keep the connector from tilting away from the board as the
cable is inserted. Since we don't have those tabs, the connector can
be held in place by gluing the body of the connector to the PCB.
The attached photo shows the USB Interface Board with these connectors
and ZIF cables in place.
For any of you who are intested in replicating this Wheelwriter
adaptation but are not antsy to jump on it right away, I suggest that
you wait for the Rev 1.8 design that I will have done soon. It
includes wiring for the additional keyboard column scan line that is
present on some other Wheelwriter models, but not the 1000, to allow
for extending the adaptation for those other models. I've also
removed the solder mask to expose the underlying board surface in the
area under where LIF connectors modified for right-angle entry are
to be glued, for more secure adhesion. And I will extend the optional
3-pin headers for I2C and UART connections to add a 4th pin for
power. My plan is to put 3.3V on the I2C header and 5V on the UART
header. This is to allow connecting a TTL-to-RS232 serial converter
such as:
http://www.nulsom.com/datasheet/NS-RS232_en.pdf
I see several similar devices but the order of the VCC, GND, RX and TX
pins varies among the devices, so there probably would not be a 1:1
mapping between the 4-pin header on the USB Interface Board and a
4-pin header on the RS232 converter. I have seen cables with a 4-pin
socket on one end and 4 separate single-pin sockets on the other end
which would allow reordering the wires as needed.
With a Rev 1.6 or Rev 1.7 board you can still use an RS232 converter
but you would need to make a connection to power on the underside of
the board.
-- Steve
Stephen Casner
Jun 8, 2019, 2:32:25 AM6/8/19
to Tom Lake, Paul Birkel, [PiDP-11]
Do you folks have a preferred TTL-to-RS232 converter device? I'm not
talking about the chip, I'm referring to the devices that mount a chip
on a small PCB right behind the 9-pin D-sub connector. And implicit
in that question is a sub-question: should the D-sub be male or female
when it is mounted on the back panel of a typewriter acting as a
hardcopy terminal? And correspondingly, should pin 2 of the D-sub
carry bits going into the typewriter to be printed or bits coming from
the typewriter's keyboard going to the computer?
My reason for asking these questions is that if there is a preferred
device I could try to match the order of the VCC, GND, RX, and TX
connections on the Rev 1.8 USB Interface Board design. That would
allow connecting with a straight-through cable with 4-pin 0.1 inch
sockets at both ends.
For reference, https://www.db9-pinout.com gives the following answers
to the sub-questions: The DTE (PC) has the male connector, and the DCE
(peripheral) has the female; pin 2 is RXD, Receive Data, going into
the PC (into pin 2 of the male connector). Assuming the PC and
peripheral are connected with a straight-through female-male cable,
that means the female connector on the peripheral (the typewriter)
would have bits coming out of pin 2 and in on pin 3. This is
consistent with https://en.wikipedia.org/wiki/Serial_port#Pinouts .
I cited one example product that comes in both male and female
genders, and these are identified as "Amazon's Choice":
http://www.nulsom.com/datasheet/NS-RS232_en.pdf
Has anyone tried these? When I read that document, it seems like
something is inconsistent among the colors they use to code the
functions and the directions of the arrow symbols used to mark the PCB
connection pads.
Amazon lists several similar products, but they vary in the order of
the VCC, GND, RX and TX connections. If one of these products is
preferred, I would try to match that order.
Several of the products use the MAX3232 chip which operates on 3.3V or
5V. They say that the RX and TX logic level is equal to the VCC
supply voltage. The Teensy 3.5 runs on 3.3V but the inputs tolerate
5V, therefore I believe it is fine for my USB Interface Board to
supply VCC = 5V on the 4-pin UART header. The RS232 converter then
runs on 5V, which may produce a higher voltage on the RS232 signals.
The high logic level of the bits going to the Teensy will be 5V, but
that's OK. The high logic level of the bits going from the Teensy to
the RS232 converter will be about 3.3V (at least 2.8V) which is still
considered logic HI by the MAX3232 when running on 5V.
-- Steve
talking about the chip, I'm referring to the devices that mount a chip
on a small PCB right behind the 9-pin D-sub connector. And implicit
in that question is a sub-question: should the D-sub be male or female
when it is mounted on the back panel of a typewriter acting as a
hardcopy terminal? And correspondingly, should pin 2 of the D-sub
carry bits going into the typewriter to be printed or bits coming from
the typewriter's keyboard going to the computer?
My reason for asking these questions is that if there is a preferred
device I could try to match the order of the VCC, GND, RX, and TX
connections on the Rev 1.8 USB Interface Board design. That would
allow connecting with a straight-through cable with 4-pin 0.1 inch
sockets at both ends.
For reference, https://www.db9-pinout.com gives the following answers
to the sub-questions: The DTE (PC) has the male connector, and the DCE
(peripheral) has the female; pin 2 is RXD, Receive Data, going into
the PC (into pin 2 of the male connector). Assuming the PC and
peripheral are connected with a straight-through female-male cable,
that means the female connector on the peripheral (the typewriter)
would have bits coming out of pin 2 and in on pin 3. This is
consistent with https://en.wikipedia.org/wiki/Serial_port#Pinouts .
I cited one example product that comes in both male and female
genders, and these are identified as "Amazon's Choice":
http://www.nulsom.com/datasheet/NS-RS232_en.pdf
Has anyone tried these? When I read that document, it seems like
something is inconsistent among the colors they use to code the
functions and the directions of the arrow symbols used to mark the PCB
connection pads.
Amazon lists several similar products, but they vary in the order of
the VCC, GND, RX and TX connections. If one of these products is
preferred, I would try to match that order.
Several of the products use the MAX3232 chip which operates on 3.3V or
5V. They say that the RX and TX logic level is equal to the VCC
supply voltage. The Teensy 3.5 runs on 3.3V but the inputs tolerate
5V, therefore I believe it is fine for my USB Interface Board to
supply VCC = 5V on the 4-pin UART header. The RS232 converter then
runs on 5V, which may produce a higher voltage on the RS232 signals.
The high logic level of the bits going to the Teensy will be 5V, but
that's OK. The high logic level of the bits going from the Teensy to
the RS232 converter will be about 3.3V (at least 2.8V) which is still
considered logic HI by the MAX3232 when running on 5V.
-- Steve
Tom Lake
Jun 8, 2019, 2:47:00 AM6/8/19
to [PiDP-11]
My favorite is the MAX3232 which has the pins in this order: GND TXD RXD VCC but we can use individual wires to connect to any scheme.
Tom L
Paul Birkel
Jun 8, 2019, 3:24:44 AM6/8/19
to Tom Lake, [PiDP-11]
WRT mixing the Teensy and the MAX232 at 5V, the following page is quite specific (and useful):
https://www.pjrc.com/teensy/td_uart.html
Adding transmit & receive LEDs to the v1.8 PCB would be a nice touch. It seems that most everyone has problems getting their serial cables properly set up and those LEDs can be a big aid in root cause analysis when “the darn’d thing doesn’t work” :->.
IMO ordering on the v1.8 PCB isn’t critical … so long as they are well-marked :->.
Following the pin ordering on the MAX3232 is certainly logical.
But then it’s also logical to follow the ordering on the “original” MAX232, which is different.
The variations seen of the amazing number of Chinese PCBs for this functionality is I suspect due to trace routing convenience along with the choice of chip - so many flavors!
All of that said, Tom makes a fine recommendation as the MAX3232 is probably the variant most commonly used by Chinese vendors currently. Let’s be pragmatic here :->.
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Tom Lake
Sent: Saturday, June 08, 2019 2:47 AM
To: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
My favorite is the MAX3232 which has the pins in this order: GND TXD RXD VCC but we can use individual wires to connect to any scheme.
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/1a91eae5-2ab5-402c-a709-2951486fbf81%40googlegroups.com.
Tom Lake
Jun 8, 2019, 3:34:52 AM6/8/19
to [PiDP-11]
I totally agree! The LEDs are a great idea and it's no big deal to connect four pins to four other pins in a different order as long as all the pins are clearly marked.
BTW, the MAX3232 has a female DB-9 connector.
Tom L
On Saturday, June 8, 2019 at 3:24:44 AM UTC-4, Paul Birkel wrote:
WRT mixing the Teensy and the MAX232 at 5V, the following page is quite specific (and useful):
https://www.pjrc.com/teensy/td_uart.html
Adding transmit & receive LEDs to the v1.8 PCB would be a nice touch. It seems that most everyone has problems getting their serial cables properly set up and those LEDs can be a big aid in root cause analysis when “the darn’d thing doesn’t work” :->.
IMO ordering on the v1.8 PCB isn’t critical … so long as they are well-marked :->.
Following the pin ordering on the MAX3232 is certainly logical.
But then it’s also logical to follow the ordering on the “original” MAX232, which is different.
The variations seen of the amazing number of Chinese PCBs for this functionality is I suspect due to trace routing convenience along with the choice of chip - so many flavors!
David Richards
Jun 8, 2019, 3:36:44 AM6/8/19
to [PiDP-11]
Hi Tom,
I use the so called RS232 to TTL converters like the one pictured quite a lot. There are pitfalls though. The handshake lines are unconnected on the four pin TTL ones I have, this is a pity since the MAX3232 on the board has two in and two out channels half of which are unused.
I have found sources of boards with six pin TTL connectors and these have Tx, Rx, RTS, and CTS connected. These usually have 9 way D sockets, although I have found a source on ebay with a 9 pin plug.
Another problem I have see is that the clone MAX3232 chips are not very good. They can do funny things and generate garbage on the bus, I have bought genuine replacement compatible chips to solve this problem, Sipex SP3232EEP. These are available without the premium price demanded for genuine MAX3232 parts.
hth David.
Paul Birkel
Jun 8, 2019, 4:07:58 AM6/8/19
to David Richards, [PiDP-11]
Indeed. This is why, earlier, I recommended going with the 5V pin so that I can ensure that I have a *good* MAX IC as well as to provide a bit of future proofing in case I come up with a reason to employ the second channel, at which point I’d certainly be rolling my own daughterboard.
Has anyone verified that one of those little DB-attached boards physically fits in the target case? It’s generally easier to fit a DB-connector in a nice-looking location and then run wiring from there to any-old-place where a daughterboard can be fit. Given the broadened range of target printers proposed IMO we shouldn’t assume that the integrated DB-and-MAX is always going to work/fit …
As for flow-control, how fast do you expect to want to “burp” data at a hard-copy printer ;->? (And how much buffering is being supported in the Teensy?) That said, I didn’t hear a proposal yet to bring those control signals to the Teensy and write the software to employ them (presumably along with a deeper buffer). Did I just hear a volunteer :->?
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of David Richards
Sent: Saturday, June 08, 2019 3:37 AM
To: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
Hi Tom,
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/5d634779-214c-400b-8c16-c71ee78c520a%40googlegroups.com.
Johnny Billquist
Jun 8, 2019, 5:54:55 AM6/8/19
to pid...@googlegroups.com
I'm just going to make a couple of general comments, since (as usual)
there is a lot of confusion around this topic.
To start with, the connector you are talking about is not a DB9 (that
URL really takes the price for showing that they do not understand).
The connector is really a DE9. The second letter is telling the size of
the shell. A DB9 would be a rather large connector with only 9 pins in
it. (And for reference, the VGA connector is a DE15 - same size,
different number of pins.)
Second, both computers and peripherals should be DTEs. A DCE is
something like a modem (DCE = Data Communication Equipment). Terminals,
computers, printers, whatever, are all DTEs.
As such, you should normally use a crossed cable between any two
devices, unless one of them is a modem. And between any device and a
modem, you have a straight cable.
As far as gender goes, it's a bit up in the air, since RS232 does not
define anything for a DE9, so the best might be to try and follow what
IBM did on the PC, as that is the pinout you also are following (which
is a rather weird pinout compared to the RS232 DB25 connector that the
standard have).
And if I remember right, the PC have a male connector, so that would
suggest that all your DTE equipment should have male connectors as well.
Female connectors should then only be on DCEs.
And cables with same connectors on both ends should be crossed, and
cables with different connectors on both ends should be straight.
Flow control using modem signalling is an option these days, so you
might want to wire some of that up as well.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
there is a lot of confusion around this topic.
To start with, the connector you are talking about is not a DB9 (that
URL really takes the price for showing that they do not understand).
The connector is really a DE9. The second letter is telling the size of
the shell. A DB9 would be a rather large connector with only 9 pins in
it. (And for reference, the VGA connector is a DE15 - same size,
different number of pins.)
Second, both computers and peripherals should be DTEs. A DCE is
something like a modem (DCE = Data Communication Equipment). Terminals,
computers, printers, whatever, are all DTEs.
As such, you should normally use a crossed cable between any two
devices, unless one of them is a modem. And between any device and a
modem, you have a straight cable.
As far as gender goes, it's a bit up in the air, since RS232 does not
define anything for a DE9, so the best might be to try and follow what
IBM did on the PC, as that is the pinout you also are following (which
is a rather weird pinout compared to the RS232 DB25 connector that the
standard have).
And if I remember right, the PC have a male connector, so that would
suggest that all your DTE equipment should have male connectors as well.
Female connectors should then only be on DCEs.
And cables with same connectors on both ends should be crossed, and
cables with different connectors on both ends should be straight.
Flow control using modem signalling is an option these days, so you
might want to wire some of that up as well.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Paul Birkel
Jun 8, 2019, 6:32:09 AM6/8/19
to Johnny Billquist, pid...@googlegroups.com
Of course "these days" we'd be using USB, not age-old RS-232 :->.
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
Sent: Saturday, June 08, 2019 5:55 AM
To: pid...@googlegroups.com
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Johnny Billquist
Sent: Saturday, June 08, 2019 5:55 AM
To: pid...@googlegroups.com
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/a2b57cd7-3434-638b-6415-4dff3b740ae8%40softjar.se.
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
david_...@brown.edu
Jun 8, 2019, 8:03:06 AM6/8/19
to Paul Birkel, pid...@googlegroups.com
The DE9 became common with the PC, previously the DB25 was more prevalent, especially with modems. For terminals and printers, three wires were often enough to get by. In fact our science building at Puget Sound University had rooms patched together on current loop using big microphone jacks and plugs. We had an LSI11 there and the big 11/70 in the administration building. This was 1975-79.
-- ddj
Dave Johnson
> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/089001d51de5%2472fe91a0%2458fbb4e0%24%40gmail.com.
-- ddj
Dave Johnson
Tom Lake
Jun 8, 2019, 10:12:11 AM6/8/19
to [PiDP-11]
You might as well give up. The term DB9 is so entrenched that everyone understands what it means.
Digi-Key avoids the problem altogether by calling ALL sizes "D-Sub".
If you google it, you'll find thousands of references to DB9 connectors. Even major players like L-com call it a DB9.
At least Wikipedia gets it right. Personally, I'd rather have an Aston Martin DB9.
Tom L
Stephen Casner
Jun 8, 2019, 10:29:25 AM6/8/19
to Tom Lake, [PiDP-11]
On Fri, 7 Jun 2019, Tom Lake wrote:
> My favorite is the MAX3232 which has the pins in this order: GND TXD RXD
> VCC but we can use individual wires to connect to any scheme.
Thanks for the reply. Do you have a reference for who makes the
> My favorite is the MAX3232 which has the pins in this order: GND TXD RXD
> VCC but we can use individual wires to connect to any scheme.
MAX3232 and where to buy? Since that is also the number of the Maxim
chip that several of these products use, it is not clear as a product
name.
The terms TXD and RXD are not always clear because in the
standard specifies that bits come out of the TxD pin for the DTE but
go in the TxD pin for the DCE. Since with the DE9 connectors the DTE
(e.g., the PC) is normally male and the DCE is normally female, and
since the MAX3232 that you prefer is a female connector, those terms
could mean either direction. Which is it?
I like the fact that the Nulsom devices use arrow symbols instead,
except that, as I mentioned, their document seems internally
inconsistent or the devices have the pin assignments backwards. I
decided to buy a pair of them to check out.
-- Steve
toml...@gmail.com
Jun 8, 2019, 10:44:33 AM6/8/19
to Stephen Casner, [PiDP-11]
NulSom Inc. in Korea makes one. I usually just get them on Amazon or eBay.
Tom L
Sent from Mail for Windows 10
From: Stephen Casner
Sent: Saturday, June 8, 2019 10:29 AM
To: Tom Lake
Cc: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
On Fri, 7 Jun 2019, Tom Lake wrote:
Paul Birkel
Jun 8, 2019, 10:51:36 AM6/8/19
to Stephen Casner, Tom Lake, [PiDP-11]
Mouser reports 7 cut-tape flavors by Maxim: https://www.mouser.com/Maxim-Integrated/Semiconductors/Interface-ICs/RS-232-Interface-IC/MAX3232-Series/_/N-45lx1?P=1yylnzmZ1yz3sqoZ1z0jmic
11 cut-tape flavors by TI: https://www.mouser.com/Texas-Instruments/Semiconductors/Interface-ICs/RS-232-Interface-IC/MAX3232-Series/_/N-45lx1?P=1yylnzmZ1z0zls6Z1z0jmic
But if you're like me, you'd buy PDIP where there are two choices -- both from MAXIM:
https://www.mouser.com/Maxim-Integrated/Semiconductors/Interface-ICs/RS-232-Interface-IC/MAX3232-Series/_/N-45lx1?P=1yylnzmZ1yz3sqoZ1z0z44d
https://www.mouser.com/ProductDetail/Maxim-Integrated/MAX3232CPE%2b?qs=sGAEpiMZZMtnIqnDeWcRHUtumypDpQDC7T1H3Yfwzxc%3D
https://www.mouser.com/ProductDetail/Maxim-Integrated/MAX3232EPE%2b?qs=sGAEpiMZZMtnIqnDeWcRHR6xtOjivA6uUVoZ3I8pQho%3D
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Saturday, June 08, 2019 10:29 AM
To: Tom Lake
11 cut-tape flavors by TI: https://www.mouser.com/Texas-Instruments/Semiconductors/Interface-ICs/RS-232-Interface-IC/MAX3232-Series/_/N-45lx1?P=1yylnzmZ1z0zls6Z1z0jmic
But if you're like me, you'd buy PDIP where there are two choices -- both from MAXIM:
https://www.mouser.com/Maxim-Integrated/Semiconductors/Interface-ICs/RS-232-Interface-IC/MAX3232-Series/_/N-45lx1?P=1yylnzmZ1yz3sqoZ1z0z44d
https://www.mouser.com/ProductDetail/Maxim-Integrated/MAX3232CPE%2b?qs=sGAEpiMZZMtnIqnDeWcRHUtumypDpQDC7T1H3Yfwzxc%3D
https://www.mouser.com/ProductDetail/Maxim-Integrated/MAX3232EPE%2b?qs=sGAEpiMZZMtnIqnDeWcRHR6xtOjivA6uUVoZ3I8pQho%3D
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Saturday, June 08, 2019 10:29 AM
To: Tom Lake
Cc: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/alpine.OSX.2.21.9999.1906080717290.8679%40auge.attlocal.net.
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
Tom Lake
Jun 8, 2019, 10:54:43 AM6/8/19
to [PiDP-11]
Those are just the chips, though. I'd need a chip mounted on a board with a DE9 connector.
Tom L
To unsubscribe from this group and stop receiving emails from it, send an email to pid...@googlegroups.com.
Stephen Casner
Jun 8, 2019, 10:56:57 AM6/8/19
to Paul Birkel, Tom Lake, [PiDP-11]
On Sat, 8 Jun 2019, Paul Birkel wrote:
> WRT mixing the Teensy and the MAX232 at 5V, the following page is
> quite specific (and useful):
>
> https://www.pjrc.com/teensy/td_uart.html
The circuit diagram there shows the original MAX232 chip which
> WRT mixing the Teensy and the MAX232 at 5V, the following page is
> quite specific (and useful):
>
> https://www.pjrc.com/teensy/td_uart.html
requires 5V. It is shown with direct connections to a Teensy 2.0, so
I guess that version must have 5V-tolerant inputs. That is also true
for the Teensy 3.5 that we use for this project, but not for the
Teensy 3.6.
> Adding transmit & receive LEDs to the v1.8 PCB would be a nice
> touch. It seems that most everyone has problems getting their
> serial cables properly set up and those LEDs can be a big aid in
> root cause analysis when "the darn'd thing doesn't work" :->.
> IMO ordering on the v1.8 PCB isn't critical ... so long as they are
> well-marked :->.
I agree that it is not critical. I have had markings TXD and RXD on
the 1.6 and 1.7 revs that have only 3 pins brought out, no VCC. In
this case, those terms mean that bits come out of the TXD pad and into
the RXD pad. Maybe on the 1.8 I can add arrows, too.
> Indeed. This is why, earlier, I recommended going with the 5V pin
> so that I can ensure that I have a *good* MAX IC as well as to
> provide a bit of future proofing in case I come up with a reason to
> employ the second channel, at which point I'd certainly be rolling
> my own daughterboard.
I will have a 3.3V pad on the row with the I2C pins, so that would
still be available, too, just not on an in-line header.
> Has anyone verified that one of those little DB-attached boards
> physically fits in the target case? It's generally easier to fit a
> DB-connector in a nice-looking location and then run wiring from
> there to any-old-place where a daughterboard can be fit. Given the
> broadened range of target printers proposed IMO we shouldn't assume
That was one aspect of the Nulsom devices that appealed to me. The
PCB is no wider than the back of the DE9 connector, so it could be
mounted from the outside of the backpanel on the Wheelwriter and feed
through a hole sized to fit the connector body. It could be attached
with jackscrews.
> As for flow-control, how fast do you expect to want to "burp" data
> at a hard-copy printer ;->? (And how much buffering is being
> supported in the Teensy?) That said, I didn't hear a proposal yet
> to bring those control signals to the Teensy and write the software
> to employ them (presumably along with a deeper buffer). Did I just
> hear a volunteer :->?
varying speed depending on wheel position, shifting, etc. But we
don't have enough pins open on the Teensy to do the hardware RTS/CTS
flow control. Instead, software XON/XOFF is implemented. Would you
folks consider that a significant restriction?
-- Steve
Tom Lake
Jun 8, 2019, 2:26:56 PM6/8/19
to [PiDP-11]
If it's XON/XOFF or nothing, then we'll have to accept it! What baud rate are we talking?
A Teletype model 33 operates at 110 baud or about 10 char/sec.
Would that be slow enough for a 1000 to keep up without handshaking?
Tom L
Paul Birkel
Jun 8, 2019, 3:01:26 PM6/8/19
to Tom Lake, [PiDP-11]
I would think so; the few performance statements that I can find for the Wheelwriter 1000 state “16 CPS bi-directional”,
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Tom Lake
Sent: Saturday, June 08, 2019 2:27 PM
To: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
If it's XON/XOFF or nothing, then we'll have to accept it! What baud rate are we talking?
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/1e48ac69-4bea-4185-80de-499cb1354327%40googlegroups.com.
Stephen Casner
Jun 8, 2019, 4:32:59 PM6/8/19
to Johnny Billquist, pid...@googlegroups.com
On Sat, 8 Jun 2019, Johnny Billquist wrote:
> I'm just going to make a couple of general comments, since (as usual) there is
> a lot of confusion around this topic.
>
> To start with, the connector you are talking about is not a DB9 (that URL
> really takes the price for showing that they do not understand).
>
> The connector is really a DE9. The second letter is telling the size of the
> shell. A DB9 would be a rather large connector with only 9 pins in it. (And
> for reference, the VGA connector is a DE15 - same size, different number of
> pins.)
I know this very well, and have often pointed out that correction to
> I'm just going to make a couple of general comments, since (as usual) there is
> a lot of confusion around this topic.
>
> To start with, the connector you are talking about is not a DB9 (that URL
> really takes the price for showing that they do not understand).
>
> The connector is really a DE9. The second letter is telling the size of the
> shell. A DB9 would be a rather large connector with only 9 pins in it. (And
> for reference, the VGA connector is a DE15 - same size, different number of
> pins.)
others. It is unfortunate that the website I referenced uses "db9" as
part of its URL, but note that the title at the top of the page is
"D-sub 9 Connector Pinout" and the next line is "Pinout and diagram of
DE9 connector (DB9 connector)". So the author of that page knows what
is correct, too.
> Second, both computers and peripherals should be DTEs. A DCE is something like
> a modem (DCE = Data Communication Equipment). Terminals, computers, printers,
> whatever, are all DTEs.
Terminal Equipment. But I recognize that opinions vary on this
topic. That's why I posed my questions.
> As such, you should normally use a crossed cable between any two devices,
> unless one of them is a modem. And between any device and a modem, you have a
> straight cable.
>
> As far as gender goes, it's a bit up in the air, since RS232 does not define
> anything for a DE9, so the best might be to try and follow what IBM did on the
> PC, as that is the pinout you also are following (which is a rather weird
> pinout compared to the RS232 DB25 connector that the standard have).
>
> And if I remember right, the PC have a male connector, so that would suggest
> that all your DTE equipment should have male connectors as well.
>
> Female connectors should then only be on DCEs.
>
> And cables with same connectors on both ends should be crossed, and cables
> with different connectors on both ends should be straight.
crossing and gender, although it is possible to find any combination.
> Flow control using modem signalling is an option these days, so you might want
> to wire some of that up as well.
assignments to allow RTS/CTS.
-- Steve
Dave Babcock
Jun 8, 2019, 5:11:16 PM6/8/19
to pid...@googlegroups.com
FYI. Some more information about our Wheelwriter 1000-based
ASCII terminal.
The emulation firmware currently has enough input and print
buffer space to store about 2 pages of output. So, high-speed
bursts of computer output can be accommodated while the print
mechanism catches up. The Teensy 3.5 micro-controller, interface
hardware, and firmware has no problem keeping up with USB serial
speed output. As Steve mentioned, the firmware currently uses
XON/XOFF flow control when the buffers are filling up, but he's
investigating how to support CTS/RTS.
The current configuration of the Wheelwriter 1000 with our USB
Interface Board brings out the USB serial line to a USB-B
connector on the back of the typewriter. A USB connection can be
made directly with the PiDP-8 or PiDP-11. Here's a link to the
[slightly out-of-date] guide to adapting the Wheelwriter 1000.
[Note that a modification is needed to the rev 1.6 board, there is
a newer rev 1.7 board available, and a rev 1.8 board is in the
works.]
https://github.com/IBM-1620/Junior/raw/master/docs/wheelwriter-adaptation-instructions.pdf
Most characters do print at [approximately] the 16cps rate. The speed degrades a little when sequential characters to print are on opposite sides of the printwheel. It also takes a second for the carriage to return from the far left column.
Finally, there are several standard ASCII characters [<, >,
\, ^, `, {, |, }, and ~)] which aren't on the printwheel and are
formed using "period graphics" and/or overprinted characters.
Period graphics are a combination of sub-character spacing and
printing periods. These characters print much slower than 16cps.
Sample output is attached.
Thanks,
Dave
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/093e01d51
Johnny Billquist
Jun 8, 2019, 6:24:15 PM6/8/19
to pid...@googlegroups.com
Maybe worth pointing out that if you are hooked up to any DEC OS, they
do only implement XON/XOFF flow control, so I would in fact suspect that
this would be preferrable to hardware flow control.
Johnny
> <https://groups.google.com/d/msgid/pidp-11/1e48ac69-4bea-4185-80de-499cb1354327%40googlegroups.com?utm_medium=email&utm_source=footer>.
do only implement XON/XOFF flow control, so I would in fact suspect that
this would be preferrable to hardware flow control.
Johnny
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/1e48ac69-4bea-4185-80de-499cb1354327%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/1e48ac69-4bea-4185-80de-499cb1354327%40googlegroups.com?utm_medium=email&utm_source=footer>.
Tom Lake
Jun 8, 2019, 9:45:53 PM6/8/19
to [PiDP-11]
You could always replace the print wheel with the OCR-A wheel which does have the missing characters
Tom L
Dave Babcock
Jun 8, 2019, 10:24:54 PM6/8/19
to [PiDP-11]
That would be great if it contains all of the ASCII characters. I couldn't find a complete character set for the wheel online. I've ordered one to check it out. We have been using the printwheel that we selected that best matched the IBM 1620 output. For that, we only needed to overprint a few special characters - no period graphics.
Thanks for the suggestion.
Dave
Tom Lake
Jun 9, 2019, 3:26:00 PM6/9/19
to [PiDP-11]
Hmmm. It may not have ALL the missing characters after all. The sample I saw was supposedly from that wheel and did have all the ASCII set but I asked the guy who has it for another full sample printout and he is hesitating.
Wheel see! (Sorry for the groaner!)
Tom L
Stephen Casner
Jun 12, 2019, 3:09:42 AM6/12/19
to Tom Lake, [PiDP-11]
Well, I have rendered moot my consideration of matching the order of
GND TXD RXD VCC pads on a DE9 connector with MAX3232 chip attached.
I was able to compress a group of signal traces on the Wheelwriter USB
Interface Board to create enough space to put a MAX3232 chip on the
board itself, so now only a plain DE9 connector is needed. We decided
to bump the board revision number up to 2.0 for this. I'm supplying
5V to the MAX3232 chip so that you can use an old MAX232 instead if
you have one lying around.
I also was able to add LEDs on the RXD and TXD signals as some of you
requested, and I rearranged some pin assignments so that hardware flow
control with RTS/CTS is possible.
So now a revised question: I'm considering what type of connection
should be provided for the cable going to the DE9 connector. My
initial idea was a 1x6 header with GND, RXD, TXD, RTS, CTS, chassis
GND as the signals. This assumes that the wires are individually
soldered to the DE9 at the other end. But another idea would be to
allow for using a DE9 connector that attaches to a ribbon cable with
insulation displacement connector (IDC) pins. On the board end of the
ribbon cable would be an IDC connector to mate with one of several
different types of connectors that fit a 2x5 header pattern.
Is the ribbon cable idea worthwhile, or would you rather just have a
1x6 pattern where you can install a 3, 5 or 6 pin header depending
upon how many wires you plan to run?
-- Steve
GND TXD RXD VCC pads on a DE9 connector with MAX3232 chip attached.
I was able to compress a group of signal traces on the Wheelwriter USB
Interface Board to create enough space to put a MAX3232 chip on the
board itself, so now only a plain DE9 connector is needed. We decided
to bump the board revision number up to 2.0 for this. I'm supplying
5V to the MAX3232 chip so that you can use an old MAX232 instead if
you have one lying around.
I also was able to add LEDs on the RXD and TXD signals as some of you
requested, and I rearranged some pin assignments so that hardware flow
control with RTS/CTS is possible.
So now a revised question: I'm considering what type of connection
should be provided for the cable going to the DE9 connector. My
initial idea was a 1x6 header with GND, RXD, TXD, RTS, CTS, chassis
GND as the signals. This assumes that the wires are individually
soldered to the DE9 at the other end. But another idea would be to
allow for using a DE9 connector that attaches to a ribbon cable with
insulation displacement connector (IDC) pins. On the board end of the
ribbon cable would be an IDC connector to mate with one of several
different types of connectors that fit a 2x5 header pattern.
Is the ribbon cable idea worthwhile, or would you rather just have a
1x6 pattern where you can install a 3, 5 or 6 pin header depending
upon how many wires you plan to run?
-- Steve
Paul Birkel
Jun 12, 2019, 3:39:30 AM6/12/19
to Stephen Casner, Tom Lake, [PiDP-11]
These are _really_ great improvements; thank you!
The 2x5 Pin IDC Ribbon Cable approach is pretty common and would be thus "more standard". At least in the IBM PC world.
https://developer.toradex.com/knowledge-base/assembling-serial-idc-to-db9-cable illustrates the standard pin assignments.
https://www.crystalfontz.com/product/wr232y08-db9-to-ten-pin-cable also
https://www.crystalfontz.com/products/document/1887/WR232Y08.pdf sample schematic.
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Wednesday, June 12, 2019 3:10 AM
To: Tom Lake
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/alpine.OSX.2.21.9999.1906112346570.14745%40auge.attlocal.net.
The 2x5 Pin IDC Ribbon Cable approach is pretty common and would be thus "more standard". At least in the IBM PC world.
https://developer.toradex.com/knowledge-base/assembling-serial-idc-to-db9-cable illustrates the standard pin assignments.
https://www.crystalfontz.com/product/wr232y08-db9-to-ten-pin-cable also
https://www.crystalfontz.com/products/document/1887/WR232Y08.pdf sample schematic.
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Wednesday, June 12, 2019 3:10 AM
To: Tom Lake
Cc: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/alpine.OSX.2.21.9999.1906112346570.14745%40auge.attlocal.net.
Tom Lake
Jun 12, 2019, 3:39:37 AM6/12/19
to pid...@googlegroups.com
Whoo! You've been busy!
As much as I like using IDC, I'd say use individual pins. That would give more flexibility in the pinout.
Any idea of when we might be able to order the new board and download a BOM?
Tom L
Stephen Casner
Jun 12, 2019, 3:36:52 PM6/12/19
to Paul Birkel, Tom Lake, [PiDP-11]
Thanks for the replies. I guess it stands to reason, if I ask a
question about A or B preference I'm bound to get a split result.
Tom, what connection method do you envision when you say "use
individual pins"? At the DE9 end, certainly you could use a connector
with solder cups for individual wires. But at the board end, what
method would you use to terminate those wires? If soldering wires
directly to the board, it doesn't matter if the traces are routed to
a 2x5 pattern. If you don't need RTS/CTS, you could still use a 1x4
header and socket, but if you need RTS/CTS as well you'd need to add
another 1x2 header and socket or use a 2x4 or 2x5 header and socket
rather than just a 1x5 or 1x6 socket if I didn't use the 2x5 pattern.
As I mentioned, I'm planning to include a connection for "chassis GND"
or "protective earth" which will conduct through one of the board
mounting studs to the aluminum shield that covers the inside of the
base of the Wheelwriter (at least in some models). If I go with the
IDC connection method, this would be pin 10 of the 2x5 connector on
the board. You could use a 9-wire ribbon cable that just connects to
all the pins on the DE9 and just doesn't connect to pin 10 on the
board end, or you could use a 10-wire ribbon cable and split out the
10th wire at the DE9 end to connect to the shell using a ring terminal
under the nut on the mounting jackscrew.
-- Steve
p.s. Tom, since you've already ordered the Rev 1.7 boards, on those
you would use a 1x3 header to pick up TTL/CMOS-level RXD, TXD and
GND to go to a DE9+MAX3232 chip.
On Wed, 12 Jun 2019, Paul Birkel wrote:
> These are _really_ great improvements; thank you!
> The 2x5 Pin IDC Ribbon Cable approach is pretty common and would be
> thus "more standard". At least in the IBM PC world.
question about A or B preference I'm bound to get a split result.
Tom, what connection method do you envision when you say "use
individual pins"? At the DE9 end, certainly you could use a connector
with solder cups for individual wires. But at the board end, what
method would you use to terminate those wires? If soldering wires
directly to the board, it doesn't matter if the traces are routed to
a 2x5 pattern. If you don't need RTS/CTS, you could still use a 1x4
header and socket, but if you need RTS/CTS as well you'd need to add
another 1x2 header and socket or use a 2x4 or 2x5 header and socket
rather than just a 1x5 or 1x6 socket if I didn't use the 2x5 pattern.
As I mentioned, I'm planning to include a connection for "chassis GND"
or "protective earth" which will conduct through one of the board
mounting studs to the aluminum shield that covers the inside of the
base of the Wheelwriter (at least in some models). If I go with the
IDC connection method, this would be pin 10 of the 2x5 connector on
the board. You could use a 9-wire ribbon cable that just connects to
all the pins on the DE9 and just doesn't connect to pin 10 on the
board end, or you could use a 10-wire ribbon cable and split out the
10th wire at the DE9 end to connect to the shell using a ring terminal
under the nut on the mounting jackscrew.
-- Steve
p.s. Tom, since you've already ordered the Rev 1.7 boards, on those
you would use a 1x3 header to pick up TTL/CMOS-level RXD, TXD and
GND to go to a DE9+MAX3232 chip.
On Wed, 12 Jun 2019, Paul Birkel wrote:
> These are _really_ great improvements; thank you!
> The 2x5 Pin IDC Ribbon Cable approach is pretty common and would be
> thus "more standard". At least in the IBM PC world.
On Wed, 12 Jun 2019, Tom Lake wrote:
> Whoo! You've been busy!
>
> As much as I like using IDC, I'd say use individual pins. That would give
> more flexibility in the pinout.
>
> Tom L
> Whoo! You've been busy!
>
> As much as I like using IDC, I'd say use individual pins. That would give
> more flexibility in the pinout.
>
>
> -----Original Message-----
> From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
> Sent: Wednesday, June 12, 2019 3:10 AM
> To: Tom Lake
> Cc: [PiDP-11]
> Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
>
> -----Original Message-----
> From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
> Sent: Wednesday, June 12, 2019 3:10 AM
> To: Tom Lake
> Cc: [PiDP-11]
> Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
>
Paul Birkel
Jun 12, 2019, 4:08:07 PM6/12/19
to Stephen Casner, Tom Lake, [PiDP-11]
Heck, I'll work with anything that gives me solder-points (preferably
labeled). I think that you're doing a great job, so don't let me dissuade
you from your chosen path.
However if you're designing for future use in a variety of mechanisms it's
not a bad idea to leverage well-known footprints, pinouts, and connectors.
They're all "dirt cheap". Also pretty "error free". Point-to-point wiring
is subject to a variety of ills. A nice "plugged" ribbon cable with
standard ends, well, much less so :->.
labeled). I think that you're doing a great job, so don't let me dissuade
you from your chosen path.
However if you're designing for future use in a variety of mechanisms it's
not a bad idea to leverage well-known footprints, pinouts, and connectors.
They're all "dirt cheap". Also pretty "error free". Point-to-point wiring
is subject to a variety of ills. A nice "plugged" ribbon cable with
standard ends, well, much less so :->.
Tom Lake
Jun 12, 2019, 4:12:52 PM6/12/19
to [PiDP-11]
For me, the standard IDC connection would be perfect. We wouldn't have to make a cable. We could just use a PC cable the way I did with my Altair 8800c. I was just thinking of someone who might want to customize the cable at the interface end rather than the DE9 end.
You wouldn't believe the pent-up demand for printing terminals! I already have 5 orders for making these machines and word is spreading fast. I just wish there was a tractor feed option!
Since we have to order three boards at a time, I'll use the first three rev 1.7 boards and then wait for the 2.x boards to fill the rest of the orders. Of course I'm keeping one machine for myself. The components and Wheelwriters are here. I'm just waiting for the boards themselves.
Dave Babcock
Jun 12, 2019, 6:34:41 PM6/12/19
to [PiDP-11]
Tom,
Attached is a sample of the OCR-A output along with the Artisan font we are currently using.
I appreciate the suggestion anyway.
Thanks,
Dave
Dave
Tom Lake
Jun 12, 2019, 6:43:48 PM6/12/19
to [PiDP-11]
But I like wonky! :) If you don't want the OCR-A wheel, I'll gladly buy it from you at the price you paid for it (plus shipping, of course) I feel bad that you spent money on my recommendation that turned out to be wrong. Plus, I really do like the OCR-A characters.
Tom L
Stephen Casner
Jun 13, 2019, 6:04:53 PM6/13/19
to Paul Birkel, Tom Lake, [PiDP-11]
On Wed, 12 Jun 2019, Paul Birkel wrote:
> Heck, I'll work with anything that gives me solder-points (preferably
> labeled). I think that you're doing a great job, so don't let me dissuade
> you from your chosen path.
Labels for sure. I've had them on the UART solder points since the
> Heck, I'll work with anything that gives me solder-points (preferably
> labeled). I think that you're doing a great job, so don't let me dissuade
> you from your chosen path.
first version of this board.
> However if you're designing for future use in a variety of mechanisms it's
> not a bad idea to leverage well-known footprints, pinouts, and connectors.
> They're all "dirt cheap". Also pretty "error free". Point-to-point wiring
> is subject to a variety of ills. A nice "plugged" ribbon cable with
> standard ends, well, much less so :->.
cables available for less than the cost of the components. So that
definitely seems like a good design choice. However, it might not be
error-free: I discovered that there are two wiring standards,
AT-Everex and DTK/Intel. In AT-Everex, pins 1-9 of the DE9 are wired
by the numbers to pins 1-9 of the IDC10. These are made by soldering
the wires at the DE9. The DTK/Intel spec wires pins 1-9 of the DE9 to
pins 1, 3, 5, 7, 9, 2, 4, 6, 8 of the IDC 10 which is what you get
when you use an IDC DE9 without rearranging the ribbon wires. There's
also a third variation for newer PC motherboards that changed the
IDC10 connector from 2.54mm (0.1") pitch to 2mm pitch. Also, many of
the standard products have a cable length of 12", which might just
reach the back panel of the Wheelwriter where we'd like to mount the
DE9, and that would be routed in a straight line underneath the
carriage's cable, which isn't ideal. Some of the cables are even
shorter and would not reach; 20 inches would be best for clean
routing.
There's also a problem that the ready-made cables I've found so far
are designed for mounting behind a thin metal plate with a plastic
cover over the back side of the connector. The back panel of the
Wheelwriter where we'd like to mount the DE9 is plastic 0.075" thick
so with the DE9 were mounted behind that panel the jackscrews on the
front of the panel would sit too tall and prevent the DE9 plug from
mating all the way. One alternative would be to buy a ready-made
cable that comes mounted to a PC chassis backplate. You could cut off
the two ends of the backplate leaving it 2.75" long, cut a bigger
hole in the plastic back panel so the whole back side of the connector
fits through, and screw the metal plate to the plastic panel. The
width of the plate is a good fit to the back panel height.
So, I choose the DTK/Intel wiring so that IDC connectors can be used
at both ends for those who want to build up their own cables, and
2.54mm pitch to allow other kinds of header sockets.
-- Steve
Stephen Casner
Jun 13, 2019, 8:21:33 PM6/13/19
to [PiDP-11]
Yesterday I said:
> I was able to compress a group of signal traces on the Wheelwriter USB
> Interface Board to create enough space to put a MAX3232 chip on the
> board itself, so now only a plain DE9 connector is needed. We decided
> to bump the board revision number up to 2.0 for this. I'm supplying
> 5V to the MAX3232 chip so that you can use an old MAX232 instead if
> you have one lying around.
I'm rethinking the choice to use the 5V supply rather than 3.3V. I
> I was able to compress a group of signal traces on the Wheelwriter USB
> Interface Board to create enough space to put a MAX3232 chip on the
> board itself, so now only a plain DE9 connector is needed. We decided
> to bump the board revision number up to 2.0 for this. I'm supplying
> 5V to the MAX3232 chip so that you can use an old MAX232 instead if
> you have one lying around.
had not looked carefully at the MAX3232 and MAX3232E specs to notice
that you can use 0.1uF capacitors for all four C1-C4 when operating at
3.3V, but when operating at 5V you need to use 0.47uF capacitors for
C2-C4. The higher capacitance is available in the same package size,
so fit is not a problem, but since all the other (bypass) capacitors
on the board are 0.1uF except for one bigger 10uF capacitor,
introducing another value provides an opportunity for assembly error.
Opinions? Is that overthinking or a reasonable consideration? Is the
option to use a 5V-only chip more valuable?
My chip preference would be the newer MAX3232E with 15kV ESD
protection that operates at either 3.3V or 5V.
Note that an older 5V-only MAX232A would work with all 0.1uF
capacitors, but an original MAX232 would require 1.0uF capacitors. It
looks like those would also be available in the same package size,
probably closer to the limits.
-- Steve
Paul Birkel
Jun 14, 2019, 5:27:17 AM6/14/19
to Stephen Casner, [PiDP-11]
If it's all on-board now then I have no preference as long as it's a PDIP part. Not everyone (including me) is "into" SMT soldering.
My interest was that if we needed to go off-board that we made 5v available so as to support a range of possible future enhancements :->.
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Thursday, June 13, 2019 8:22 PM
To: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
My interest was that if we needed to go off-board that we made 5v available so as to support a range of possible future enhancements :->.
-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Stephen Casner
Sent: Thursday, June 13, 2019 8:22 PM
To: [PiDP-11]
Subject: Re: [PiDP-11] Re: Hardcopy terminal emulators
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/alpine.OSX.2.21.9999.1906131613220.15674%40auge.attlocal.net.
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
Paul Birkel
Jun 14, 2019, 5:30:10 AM6/14/19
to Stephen Casner, Tom Lake, [PiDP-11]
Concur with selection of DTK/Intel spec. You *do* know how to do your
homework :->.
Agree regarding the length considerations; the rest of us aren't in a good
position to assess fit/clearance.
-----Original Message-----
From: Stephen Casner [mailto:cas...@acm.org]
Sent: Thursday, June 13, 2019 6:05 PM
To: Paul Birkel
Cc: 'Tom Lake'; '[PiDP-11]'
Subject: RE: [PiDP-11] Re: Hardcopy terminal emulators
homework :->.
Agree regarding the length considerations; the rest of us aren't in a good
position to assess fit/clearance.
-----Original Message-----
From: Stephen Casner [mailto:cas...@acm.org]
Sent: Thursday, June 13, 2019 6:05 PM
To: Paul Birkel
Cc: 'Tom Lake'; '[PiDP-11]'
Subject: RE: [PiDP-11] Re: Hardcopy terminal emulators
Tom Lake
Jun 17, 2019, 8:11:39 AM6/17/19
to [PiDP-11]
Any advance on the firmware for the Teensy? I have all the hardware ready to go but I need to load the firmware. Can it be done using the micro SD card? Now that I've cut the VIN - VUSB connection on the Teensy board, I can't power it from the USB port. I could always install a temporary jumper but I'd rather program it with an SD card if possible.
Tom L
On Monday, May 6, 2019 at 5:30:11 PM UTC-4, dave...@gmail.com wrote:
On Monday, May 6, 2019 at 5:30:11 PM UTC-4, dave...@gmail.com wrote:
Hello Jon,
Your question is very timely. We're just a few weeks away from announcing a general-purpose ASCII teleprinter.
This device is a by-product of the Computer History Museum's IBM 1620 Jr. project. It is built from an IBM/Lexmark Wheelwriter 1000 typewriter. For a parts cost of less than $150 and a few hours of work [plus the cost of a WW 1000], you can have a printing terminal which can be connected to your PiDP-11/70 or any other mini/micro/replica computer of your choosing.
Our all-volunteer team will be making all of the design, instructions, software, etc. available free to the community.
We demonstrated a converted WW attached to our historic IBM 1620 replica [aka IBM 1620 Jr.] at last fall's VCF West. We received 1st place in Best In Show and 2nd place in Best Restoration. We've since re-written the firmware to not only emulate the IBM 1620's console typewriter but also a general-purpose ASCII terminal, selectable by hardware jumpers. There's one emulation slot available in the firmware if one wants to add a specific terminal like the DECWriter.
Here's our display board from VCF West 2019 which gives more information about the creation of the terminal:
https://www.dropbox.com/s/rotbrlj7x7gx1m8/VCF_2019_display.jpg?dl=0
Here are the step-by-step directions [with photos] for adapting the WW 1000:
https://github.com/IBM-1620/Junior/raw/master/docs/wheelwriter-adaptation-instructions.pdf
As soon as we're done testing the new firmware and a modification to our USB Interface board, I'll post a notice to this mail list.
Thanks,
Dave
On Sunday, May 5, 2019 at 6:50:53 PM UTC-7, jon....@gmail.com wrote:Does anybody know of an equivalent to cool-retro-term that emulates a hardcopy terminal, such as an ASR-33 or DECWriter? I haven't really been able to find anything on Google, but it seems like it would be a cool accessory to a PiDP.
Dave Babcock
Jun 17, 2019, 12:33:55 PM6/17/19
to pid...@googlegroups.com
To all,
The firmware for our Wheelwriter ASCII Terminal is in really great shape. The latest production version (5R3) fully supports the rev 1.6 and 1.7 USB Interface Boards in a Wheelwriter 1000. It has been thoroughly tested in the IBM 1620 Console Typewriter, ASCII Terminal, and stand-alone typewriter modes.
As Steve has written, a rev 2.0 board is in the works. This will add hardware support for later model Wheelwriters which have an additional keyboard scan column. The new board also has an on-board MAX3232 chip for RS-232 serial communication. A new version of the firmware (5R4) which supports the RS-232 feature is almost complete. [We'll need access to a different Wheelwriters to update the firmware for them.]
The firmware is written in C as a "sketch" and compiled and downloaded to the Teensy via the USB port using the Arduino IDE 1.8.9 (https://www.arduino.cc/en/main/software) and Teensyduino 1.46 (https://www.pjrc.com/teensy/td_download.html) software. The Teensy needs to be installed on the USB Interface Board in a powered-up Wheelwriter 1000. The compile options are "Teensy 3.5, USB Serial, 120 MHz, Fastest with LTO".
Thanks,
Dave
P.S. Sorry for the delay in releasing this. I've been dealing
with a broken hot water pipe in the kitchen floor the past two
months.
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6938c37a-e154-4401-a141-b39b135ec2cc%40googlegroups.com.
Paul Birkel
Jun 18, 2019, 1:15:43 PM6/18/19
to Dave Babcock, pid...@googlegroups.com
But … where do I get the new firmware, please? Is there a GirHub or GitLab site?
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/9773eacc-62ad-7ae7-d944-a22c7fe1e69f%40babcock-family.org.
Reply all
Reply to author
Forward
0 new messages