Re: tty and video displays
On 12/14/20 10:06 PM, Brent Hilpert via cctalk wrote: On 2020-Dec-14, at 7:57 AM, Jules Richardson wrote: On 12/14/20 4:41 AM, Brent Hilpert via cctalk wrote: Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. It's an ASCII/APL terminal, overstriking was included for the APL mode. http://madrona.ca/e/teleray3931/index.html Holy cow, I have that keyboard. ... (It's definitely -12V, not -5V? I'm just thinking that the -12V noted on your schematic is quite close the the 15V rating on the cap - although that could explain why my later setup got caps rated to 35V, too) I don't remember whether I traced it or measured it, but I'm fairy confident, Vgg = -12 is pretty common for GI MOS ICs. I'll try to remember to double-check it when I have the unit opened again. Hey, Just a heads-up, I finally got around to hooking it up - and it works just fine on -5V. I'm not inclined to try -12V just in case it cooks, but I suppose it's possible that it just needs some -ve voltage "more than x" and so -12V is perfectly acceptable, too. Or maybe I just got lucky and this IC is happy on -5V where some might not be. I'm pretty happy that it's alive, anyway. I need to figure out what's going on with the spacebar (it currently doesn't sit level), but time to figure out some frankenproject for it! cheers Jules
Re: tty and video displays
For these interested on how it looked, I posted a picture of all the characters created by the HP 2641 APL ROM dumps here: https://www.curiousmarc.com/computing/hp-264x-terminals (somewhere down in the middle of the page). ROM dumps were from Al Kossow I believe (thanks Al). Marc > On Dec 14, 2020, at 9:00 PM, Gavin Scott via cctalk > wrote: > > Now I want to know if you have a list of the Burroughs APL > overstrikes, since HP included many more overstrike characters in the > HP 2641A than the ones that they needed for APL\3000, including (or so > I'm lead to believe) all the Burroughs extended I/O quad overstrikes, > presumably to maximize the market for the terminal and/or because they > thought they might implement the same functionality at some point. So > it would be interesting to know what was actually missing. > > The overstrike character ROM for the HP 2641A includes 63 characters, > but (IIRC) only something like 21 are used in APL\3000. > > P.S. My HP 2641A emulation will be in the next official MAME release > thanks to F.Ulivi who merged it into his existing HP 2645A driver and > got it submitted upstream. > > G. > >> On Mon, Dec 14, 2020 at 10:28 PM Stan Sieler via cctalk >> wrote: >> >> That meant that we couldn't use the terminal at Burroughs, because our APL >> had a few overstrikes that weren't in the table.
Re: tty and video displays
On 2020-Dec-15, at 11:15 AM, Jules Richardson via cctalk wrote: > On 12/14/20 10:06 PM, Brent Hilpert via cctalk wrote: >>> (It's definitely -12V, not -5V? I'm just thinking that the -12V noted >>> on your schematic is quite close the the 15V rating on the cap - >>> although that could explain why my later setup got caps rated to 35V, >>> too) >> I don't remember whether I traced it or measured it, but I'm fairy >> confident, Vgg = -12 is pretty common for GI MOS ICs. I'll try to >> remember to double-check it when I have the unit opened again. > > Thanks! I guess I can try it first on -5V too and see if the encoder outputs > do anything, and if not give -12V a go. If it works, I like the charge pump > idea - I'd probably ultimately give it its own case and use it externally, so > saving a wire is handy. Just double-checked by measurement, yes, it is -12V.
Re: tty and video displays
On 12/14/20 10:06 PM, Brent Hilpert via cctalk wrote: (It's definitely -12V, not -5V? I'm just thinking that the -12V noted on your schematic is quite close the the 15V rating on the cap - although that could explain why my later setup got caps rated to 35V, too) I don't remember whether I traced it or measured it, but I'm fairy confident, Vgg = -12 is pretty common for GI MOS ICs. I'll try to remember to double-check it when I have the unit opened again. Thanks! I guess I can try it first on -5V too and see if the encoder outputs do anything, and if not give -12V a go. If it works, I like the charge pump idea - I'd probably ultimately give it its own case and use it externally, so saving a wire is handy. cheers Jules
Re: tty and video displays
Now I want to know if you have a list of the Burroughs APL overstrikes, since HP included many more overstrike characters in the HP 2641A than the ones that they needed for APL\3000, including (or so I'm lead to believe) all the Burroughs extended I/O quad overstrikes, presumably to maximize the market for the terminal and/or because they thought they might implement the same functionality at some point. So it would be interesting to know what was actually missing. The overstrike character ROM for the HP 2641A includes 63 characters, but (IIRC) only something like 21 are used in APL\3000. P.S. My HP 2641A emulation will be in the next official MAME release thanks to F.Ulivi who merged it into his existing HP 2645A driver and got it submitted upstream. G. On Mon, Dec 14, 2020 at 10:28 PM Stan Sieler via cctalk wrote: > That meant that we couldn't use the terminal at Burroughs, because our APL > had a few overstrikes that weren't in the table.
Re: tty and video displays
Paul writes: > General overstrike requires a bitmap display, or some sort of persistent display. Although he carefully specified 'general overstrike', I'll still mention how the HP 2641A (an APL terminal) did it. When about to enter a newly received character into memory, the terminal checked if a non-blank was already in that spot ... if yes, it looked up the pair in an internal ROM table and replaced the existing character code with a new character code designed for APL\3000 (a code that, when received, would display as the appropriate overstrike). That meant that we couldn't use the terminal at Burroughs, because our APL had a few overstrikes that weren't in the table. Stan
Re: tty and video displays
On 2020-Dec-14, at 7:57 AM, Jules Richardson wrote: > On 12/14/20 4:41 AM, Brent Hilpert via cctalk wrote: >> >> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. >> It's an ASCII/APL terminal, overstriking was included for the APL mode. >> http://madrona.ca/e/teleray3931/index.html > > Holy cow, I have that keyboard. ... > (It's definitely -12V, not -5V? I'm just thinking that the -12V noted on your > schematic is quite close the the 15V rating on the cap - although that could > explain why my later setup got caps rated to 35V, too) I don't remember whether I traced it or measured it, but I'm fairy confident, Vgg = -12 is pretty common for GI MOS ICs. I'll try to remember to double-check it when I have the unit opened again. I have some other orphan keyboard of the period, don't recall which scanner IC it uses, but it has the similar +Vcc/-Vgg requirement. I made up a little negative supply with a 7660 charge pump and tacked it onto the keyboard PCB so the keyboard now only needs +5 externally.
Re: tty and video displays
On 2020-Dec-14, at 6:28 AM, Paul Koning wrote: >> On Dec 14, 2020, at 9:26 AM, emanuel stiebler via cctalk >> wrote: >> On 2020-12-14 05:41, Brent Hilpert via cctalk wrote: >>> On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote: Often for data input one could use over strike characters for input. Not EQ might be = BS | Did any video display terminals repeat the same effect? >>> >>> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. >>> It's an ASCII/APL terminal, overstriking was included for the APL mode. >>> >>> http://madrona.ca/e/teleray3931/index.html >>> >>> Note the screenshots in APL mode. >> >> Is it really an overstrike? They look simply like different characters. >> At least, I didn't (probably missed it) how they can be generated out of >> the available ones... > > I wondered too. General overstrike requires a bitmap display, or some sort > of persistent display. Paper is an example; a Tek 4010 would also handle > overstrike since it uses a storage tube. And PLATO terminals did overstrike > just fine since they are bitmap displays with per-pixel memory. Yes, it really is overstrike. This is pretty much explained in the text. You generate overstrikes by backing up and entering a 2nd character. There are two full screen buffers, but only one page of display. There is a spring-loaded 3-position switch that allows you to temporarily 'disable' either of the buffers, so that only the characters in the other buffer are on screen while you hold the switch. There are 95 symbols in the APL set encoded in the range 0x20 to 7E, as shown on the screenshots. Now I haven't tried all 9025 possible overstrike combinations, but all sorts of non-sensical combinations produce what would be the expected result - an OR of the pixels of the contributing characters. For example, "A" can be overstruck with all the other letters of the alphabet, and all the letters of the alphabet can be overstruck with "A". It's not just the valid APL overstrike combinations. A general overstrike capability like this doesn't need a bitmap display to accomplish. I haven't RE'd the character-pixel generation section, but the ICs present and the behaviour points to it doing something along the lines of: In raster scanning, for each screen character cell: - address buffer 1, send code through character generator, store result in pixel shift register. - address buffer 2, send code through character generator, OR result into pixel shift register. - shift the shift register pixels out to CRT. - repeat for next character cell
Re: tty and video displays
On 12/14/20 6:28 AM, Paul Koning via cctalk wrote: >> Is it really an overstrike? They look simply like different characters. >> At least, I didn't (probably missed it) how they can be generated out of >> the available ones... > > I wondered too. General overstrike requires a bitmap display, or some sort > of persistent display. Paper is an example; a Tek 4010 would also handle > overstrike since it uses a storage tube. And PLATO terminals did overstrike > just fine since they are bitmap displays with per-pixel memory. Back in the day (why is everything now "back in the day"?), I wrote the firmware for a Fortune Systems text terminal. The requirement was for a certain degree of NAPLPS/Videotex compatibility. Combining certain characters was done via lookup in the character generator ROM, not by combining them as graphical characters. I suspect that this was the method used for a large number of terminals, such as the Telidon units. --Chuck
Re: tty and video displays
On 12/14/20 4:41 AM, Brent Hilpert via cctalk wrote: On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote: Often for data input one could use over strike characters for input. Not EQ might be = BS | Did any video display terminals repeat the same effect? Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. It's an ASCII/APL terminal, overstriking was included for the APL mode. http://madrona.ca/e/teleray3931/index.html Holy cow, I have that keyboard. I picked it up as surplus a few years ago from a place in Minneapolis and figured there was a very low probability of ever figuring out what machine it originally came from. I didn't know the necessary voltages for it - I mean, the grounds and +5V are obvious, but I didn't know what it needed on pin 6. Given where I got it from, there's probably a fair chance that it's faulty (and encoders generally live a hard life), but I'll have to try powering it up now. Just FYI if you're documenting things, mine has a very slightly different PCB to accommodate a pair of tantalum caps on the inputs, rather than the electrolytics on yours - caps are both rated 10uF, 35V. The encoder on mine is the same p/n but in a black plastic package rather than white ceramic (date code 7649). Sticker on the PCB underside says p/n 2129-009 and s/n 720 097. (It's definitely -12V, not -5V? I'm just thinking that the -12V noted on your schematic is quite close the the 15V rating on the cap - although that could explain why my later setup got caps rated to 35V, too) cheers! Jules
Re: tty and video displays
> On Dec 14, 2020, at 9:26 AM, emanuel stiebler via cctalk > wrote: > > On 2020-12-14 05:41, Brent Hilpert via cctalk wrote: >> On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote: >>> Often for data input one could use over strike characters for input. Not EQ >>> might be = BS | Did any video display terminals >>> repeat the same effect? >> >> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. >> It's an ASCII/APL terminal, overstriking was included for the APL mode. >> >> http://madrona.ca/e/teleray3931/index.html >> >> Note the screenshots in APL mode. > > Is it really an overstrike? They look simply like different characters. > At least, I didn't (probably missed it) how they can be generated out of > the available ones... I wondered too. General overstrike requires a bitmap display, or some sort of persistent display. Paper is an example; a Tek 4010 would also handle overstrike since it uses a storage tube. And PLATO terminals did overstrike just fine since they are bitmap displays with per-pixel memory. paul
Re: tty and video displays
On 2020-12-14 05:41, Brent Hilpert via cctalk wrote: > On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote: >> Often for data input one could use over strike characters for input. Not EQ >> might be = BS | Did any video display terminals >> repeat the same effect? > > Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. > It's an ASCII/APL terminal, overstriking was included for the APL mode. > > http://madrona.ca/e/teleray3931/index.html > > Note the screenshots in APL mode. Is it really an overstrike? They look simply like different characters. At least, I didn't (probably missed it) how they can be generated out of the available ones...
Re: tty and video displays
On 12/14/20 4:26 AM, ben via cctalk wrote: Often for data input one could use over strike characters for input. Not EQ might be = BS | Did any video display terminals repeat the same effect? Ben. APL Terminals where many of the characters are overstrike. bill
Re: tty and video displays
On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote: > Often for data input one could use over strike characters for input. Not EQ > might be = BS | Did any video display terminals > repeat the same effect? Yes. Coincidentally I've just been refurbishing one - a Teleray 3931. It's an ASCII/APL terminal, overstriking was included for the APL mode. http://madrona.ca/e/teleray3931/index.html Note the screenshots in APL mode.
tty and video displays
Often for data input one could use over strike characters for input. Not EQ might be = BS | Did any video display terminals repeat the same effect? Ben.
