Keyboard Shortcuts
Likes
Search
Support for 3066 Graphic Terminal
|
Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)???
?
I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.
?
But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.
?
Thoughts?
?
cheers, William |
|
Hello, I dislike removing support from the product, but I'm not against removing 3066 console support.? Just some questions. ?When did IBM remove support for the 3066? Is it possible to add an additional register for addressability? How did IBM handle the addressability issue for DMKGRF? As I said, I'm not against removing the support for the 3066 console, but the future does concern me.? I suspect there will be other changes in the?future for DMKGRF, and removing device support won't be the solution.? Maybe adding a register now is a consideration.? Thank you. On Sun, Sep 22, 2024, 02:15 William Denton via <williamedenton=[email protected]> wrote: Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)???? I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.? But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.? Thoughts?? Cheers, William |
开云体育Bertram, Addressability and space in DMKGRF always was a problem. Well in 1985 at least one site removed the 3066 support. ? ? the suggestion of adding an extra base register was considered and discarded. I think at some point in SP IBM split the module.. ? Dave ? From: [email protected] <[email protected]> On Behalf Of Bertram Moshier via groups.io
Sent: 22 September 2024 10:22 To: [email protected] Subject: Re: [h390-vm] Support for 3066 Graphic Terminal ? Hello,
? ?When did IBM remove support for the 3066?
? Thank you. |
开云体育If this leads to dynamic screen sizes I am all for it. I already run it with a large screen size (c3270 localhost:3270 -model 3279-5 -oversize 159x48 -defaultfgbg) and the works quite nicely - for reasons beyond my comprehension of VM/370 EE actually works very well; outside of that the status indicator keeps displaying somewhere in the middle and it would be great if it could behave a bit more like modern VM. But more importantly: now I need to know what a "not" microfiche viewer is. I know about, and at various time got seasick from the microfiche viewers at university, but I do not remember ever operating a "not" microfiche viewer. best regards, 搁别苍é.
|
|
On Sun, Sep 22, 2024 at 12:17 PM, rvjansen@... wrote:
[...] for reasons beyond my comprehension of VM/370 EE actually works very well; outside of that the status indicator keeps displaying somewhere in the middle and it would be great if it could behave a bit more like modern VM.I have played around with the ZOC TN3270 emulator, EE V1.2.5. could handle 200 columns and 81 lines at first glance. There were warning messages on exit about memory overwrites though. I have seen many hard coded limits in the EE sources, this has to be reworked if (or when ?) multiple logical screens are introduced. ?
Martin |
|
On Sun, 22 Sept 2024 at 03:15, William Denton via <williamedenton=[email protected]> wrote:
Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky
I would be somewhat unhappy to see the 3066 code removed. Surely it can't be all that big...? For many years I've had an "I'll do it when I'm retired" project in mind to produce either a 3066 terminal emulator itself or the necessary Hercules code to make a suitably configured TN3270 session appear like a 3066 to the host, but of course if there's no mainframe code to drive it then there's little point. So I guess this is also nostalgia, and I may well never get to it, but I still don't like the idea of removing device support. On the details, surely there is some 3066 code and tables elsewhere in CP? Would you also remove that? If not, how would things behave? Tony H. |
|
On Sun, 22 Sept 2024 at 17:19, Tony Harminc <tharminc@...> wrote: [...] > Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky Sorry - hit ENTER (heh) too soon. There was a pushbutton switch much the shape, size, and physical feel of those used for all manner of things on IBM hardware - the LOAD/START/etc. keys, and those on things like 1403 printers that was the 3066 console ENTER key just to the right of the keyboard. But the keyboard also had a typewriter-like built-in ordinary ENTER or CR or NL key that, IIRC, did nothing, and could be adapted to actually work. Unfortunately all the pictures of the 3066 at bitsavers are poorly scanned, and I can't find anything with a clear picture or diagram of the keyboard and surrounding space. Tony H. |
开云体育Tony, If you look at the link I sent to the VMSHARE archives :- ? ? it saves about 500 bytes, which is significant in CP terms…. .. yes there is code that tests for 3066 in some other modules DMKCPx ?for example, but if non are generated this code won’t get exercised. ? Dave ? From: [email protected] <[email protected]> On Behalf Of Tony Harminc via groups.io
Sent: 22 September 2024 22:19 To: [email protected] Subject: Re: [h390-vm] Support for 3066 Graphic Terminal ? On Sun, 22 Sept 2024 at 03:15, William Denton via <williamedenton=[email protected]> wrote:
? Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky
? I would be somewhat unhappy to see the 3066 code removed. Surely it can't be all that big...? For many years I've had an "I'll do it when I'm retired" project in mind to produce either a 3066 terminal emulator itself or the necessary Hercules code to make a suitably configured TN3270 session appear like a 3066 to the host, but of course if there's no mainframe code to drive it then there's little point. ? So I guess this is also nostalgia, and I may well never get to it, but I still don't like the idea of removing device support. ? On the details, surely there is some 3066 code and tables elsewhere in CP? Would you also remove that? If not, how would things behave? ? Tony H. |
|
I've been following this thread with interest, so allow me to offer what may be, while somewhat radical, a nevertheless viable solution:
Require your Hercules control file to have a "FACILITY ENABLE HERC_370_EXTENSION" statement (after your "ARCHLVL 370" statement), and then change your code to use "Branch Relative" instructions instead: A704 Branch_Relative_on_Condition A705 Branch_Relative_and_Save A706 Branch_Relative_on_Count 84 Branch_Relative_on_Index_High 85 Branch_Relative_on_Index_Low_or_Equal which, as you may or may not know, do not require any base register at all. * S/370 Backport of select ESA/390 and z/Architecture instructions Note too, that Hercules's 370 Extension also gives you gives you access to many other very handy instructions as well (such as the "Immediate" instructions). For the complete list, see: * As I said, it IS admittedly a rather radical approach (and would never work on real hardware of course; only on Hercules), but it IS nevertheless a possible solution to consider. After all, not requiring ANY base register AT ALL would allow your module to be as big as you would need it to be! (and would free that register to be used for something else!) Just something I thought I'd throw out there. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
Hello, How about following IBM and splitting the module into two? Just a thought. On Sun, Sep 22, 2024, 18:59 Fish Fish via <david.b.trout=[email protected]> wrote: I've been following this thread with interest, so allow me to offer what may be, while somewhat radical, a nevertheless viable solution: |
|
Fish,
toggle quoted message
Show quoted text
I would prefer not to do this as I believe it would stop VM/CE running on my P/390. Dave -----Original Message----- |
|
toggle quoted message
Show quoted text
-----Original Message-----I also don't see that using the non-base register instructions help a lot. The existing code relies on base registers. The problems occur because when you insert code you exceed the range of the base registers. You would probably need to replace a lot of code to get any benefit... Dave |
|
Dave Wade wrote:
[...] I also don't see that using the non-base register instructionsYou don't?! Wow. Just... wow. The existing code relies on base registers.Which, when eliminated, would free up those registers for other uses. The problems occur because when you insert code you exceed theWhich, when replaced with relative instructions that don't need base registers, allows you to address anywhere from -128K to +128K from the current PSW (for the short form), or anywhere from -4GB to +4GB for the long form. You would probably need to replace a lot of code to get anyMore than likely, yes. But once done, you would NEVER again need to worry about blowing a base register. EVER. Your module, from then on, could grow as large as you would ever want. We're talking about a ONE TIME fix (modification/rewrite) here, to eliminate the base register problem ONCE AND FOR ALL. *Forever*. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
toggle quoted message
Show quoted text
-----Original Message-----Not at all. There are many changes to DMKGRF bobbling around the net. If you re-write it then working out how to fit these changes in becomes challenging. Dave |
|
The /168 console (like the 158 & later) didn't have very many blinky lights. As I recall, just the five above the Interrupt, Start, Stop, Load buttons.
?
So, the "not" microfiche viewer was the contraption to the left of the console that looked like a big dual-screen fiche viewer. One of the screens (as I recall, the left one) was an actual fiche viewer. The other one was the replacement for the blinky lights. It had two dials that would select row/.column in a matrix of display choices that would display (in lights behind the (lucite?) screen all the things lights should display -- PSW, regs, current address, etc. in addition to lots and lots of internal stuff...
?
Now that I think about it, the front part of the console must have had rotary switches and other buttons to do things like set the location counter, set address stop, etc... Address stop and Inst Step for sure because I remember having to come in on a Sunday afternoon to work with the CE to diagnose and fix a clock comparator bug that I had to stop the machine at a certain location in CP and step thru a few instructions after the CE had set a bunch of probes
?
Amazing what's lurking back in the dusty recesses in ones head
?
cheers, William |
开云体育William, I think more than that, looking at the Functional Characteristics manuals for these from BitSavers ? ? and I was interested to read some had a light pen…. Dave ? From: [email protected] <[email protected]> On Behalf Of William Denton via groups.io
Sent: 24 September 2024 17:25 To: [email protected] Subject: Re: [h390-vm] Support for 3066 Graphic Terminal ? The /168 console (like the 158 & later) didn't have very many blinky lights. As I recall, just the five above the Interrupt, Start, Stop, Load buttons. ? So, the "not" microfiche viewer was the contraption to the left of the console that looked like a big dual-screen fiche viewer. One of the screens (as I recall, the left one) was an actual fiche viewer. The other one was the replacement for the blinky lights. It had two dials that would select row/.column in a matrix of display choices that would display (in lights behind the (lucite?) screen all the things lights should display -- PSW, regs, current address, etc. in addition to lots and lots of internal stuff... ? Now that I think about it, the front part of the console must have had rotary switches and other buttons to do things like set the location counter, set address stop, etc... Address stop and Inst Step for sure because I remember having to come in on a Sunday afternoon to work with the CE to diagnose and fix a clock comparator bug that I had to stop the machine at a certain location in CP and step thru a few instructions after the CE had set a bunch of probes ? Amazing what's lurking back in the dusty recesses in ones head ? cheers, William |
Martin Scheffler