[Simh] VAX/VMS 3.0 Distribution Available for Download
John Dundas' distribution of VAX/VMS version 3.0 (April 1982) can now be downloaded from my Dropbox. The SYSTEM password is MANAGER. Note: Dropbox does not force you to create an account, if you look carefully you will see a "Continue to view" link at the bottom of that pop-up. Here's what it boots into: VAX/VMS Version V3.0 26-APR-1982 16:21 PLEASE ENTER DATE AND TIME (DD-MMM- HH:MM) 21-MAR-2020 11:58 %JBC-I-NEWQUEUE, new queue file created %OPCOM, 21-MAR-2020 11:58:34.51, logfile initialized by operator OPA0 logfile is SYS$MANAGER:OPERATOR.LOG Login quotas - Interactive limit=64, Current interactive value=0 SYSTEM job terminated at 21-MAR-2020 11:58:39.91 Username: SYSTEM Password: Welcome to VAX/VMS version V3.0 $ $ Grab it from https://bit.ly/vaxvms30 Regards, Supratim -- Supratim Sanyal, W1XMT 39.19151 N, 77.23432 W QCOCAL::SANYAL via HECnet ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Clem, you are right, and this have diverged a lot. I should have written it just to you instead. I apologize to all. I'm going to make the following reply public anyway, but I'm going to try and stop after this. I think that the main point Clem makes is one I agree with anyway, so it's not that there is much to argue about. So this is mostly small comments on a couple of details. On 2016-02-21 14:50, Clem Cole wrote: This discussion has very much diverged from the original topics of VAX/VMS and ISA compatibility. If folks want to discuss the actions or inactions, who did what /etc/… let’s take that off list. I will try to come back to what I started with: Some people on this list (including me), believe that Intel has done a pretty reasonable job of compatibility as it moved from generation to generation from its original 4004 microprocessor to today’s Intel*64 ISA From reading the comments, others may not think the Intel team did, fair enough.Also, other firms such as IBM and DEC had done the same with their ISA (S360 and Vax in those cases). As has been pointed out, each of three firms mentioned have injected some level of incompatibility along the way. The question of how a good a job they did is likely to be gauged on how it affected you personally. I personally find the ability to be able to boot a really old OS and run really old programs on a modern chip to be handy. Since this is a forum on simulation, I would have thought others considered that a pretty important feature. But maybe it is not. To pick on DEC (or IBM), the later generations of their respective ISAs cannot boot the older OS – which Intel’s primary ISA can – and that is what started this discussion. Agreed. On all points above. The fact that you can boot an old version of DOS on current hardware should be enough of a point to stop the discussion right now. I have also pointed out (as have others) that Intel also did not try to be compatible with all its lines, which others consider that a negative for Intel’s commitment to compatibility. And that is also the case for the other companies mentioned. The Alpha, for example, is not VAX compatible. And noone argues that this means that the VAX wasn't fairly consistent as an architecture. Just because you have one architecture does not mean you cannot ever make a different one. In fact is in almost every case except one that I can think, when Intel broke away from the compatibility path that became today's INTEL*64 ISA, Intel was not as successful in the market (I'm thinking i432, 860, 960, Itanium) – the one success I can think of where they were not compatible and were still successful was in their embedded line which was originally the 8748 (which became the 8051).I suppose it also can be pointed out that the 860/960 ended up have a fairly long life also in the embedded space and were "successful" there.But those ISAs were eventually EOL’s; while you can still find 8051 ISA based chips being manufactured today. Yes. And I'm surprised if anyone would claim that Intel was breaking some rule just because they wanted to make a chip that did not use the same ISA as the x86. Others in this list seem to object to the fact the current INTEL*64 ISA is owned and defined by Intel, not by a competing firm who originally created an extension to the x86 (ney IA-32) ISA before Intel and brought it to market in their product line. Fair enough and I personally think I understand why people might believe that and I do understand and lived the same history. But I point out that it does not change the fact that Intel owns and defines ISA, it >>is<< Intel’s ISA. Someone else does not get to call it something else when they do not own it. Just as the PDP-11, Vax & Alpha were DEC’s ISAs and S360, S/370 & Power is/was IBM’s. Well, it is a bit more complicated than that. The original x86 is Intels. The AMD extension is AMDs. AMD and Intel have a cross licensing agreement which means they can each use each others extensions and changes without any costs/legal issues/whatever. So, it's become a case of no matter who originally did it, both can implement it. So it's a case of, whatever is successful will be implemented by both, no matter who did it first. And both can extend the architecture. I guess in a way it's a case of the market decides. Think about 2 other instances, Cal Data extended the PDP-11 before DEC did and Amdahl the S/360 before IBM. As it turns out, DEC sued and put Cal Data out of business but IBM let Amdahl be. In both cases features first pioneered on those other product lines, end up in the original (although maybe with a different name and/or different implementation). But the ISA stayed S/360 and PDP-11 and the owners of each further extended their ISA along the way (S/370, now zSeries, PDP-11 begat VAX 11/780). I can't comment on Amdahl, as I don't know enough, but for Cal Data, it's not in any way meaningful to compare w
Re: [Simh] VAX/VMS
This discussion has very much diverged from the original topics of VAX/VMS and ISA compatibility. If folks want to discuss the actions or inactions, who did what *etc*… let’s take that off list. I will try to come back to what I started with: Some people on this list (including me), believe that Intel has done a pretty reasonable job of compatibility as it moved from generation to generation from its original 4004 microprocessor to today’s Intel*64 ISA From reading the comments, others may not think the Intel team did, fair enough.Also, other firms such as IBM and DEC had done the same with their ISA (S360 and Vax in those cases). As has been pointed out, each of three firms mentioned have injected some level of incompatibility along the way. The question of how a good a job they did is likely to be gauged on how it affected you personally. I personally find the ability to be able to boot a really old OS and run really old programs on a modern chip to be handy. Since this is a forum on simulation, I would have thought others considered that a pretty important feature. But maybe it is not. To pick on DEC (or IBM), the later generations of their respective ISAs cannot boot the older OS – which Intel’s primary ISA can – and that is what started this discussion. I have also pointed out (as have others) that Intel also did not try to be compatible with all its lines, which others consider that a negative for Intel’s commitment to compatibility. In fact is in almost every case except one that I can think, when Intel broke away from the compatibility path that became today's INTEL*64 ISA, Intel was not as successful in the market (I'm thinking i432, 860, 960, Itanium) – the one success I can think of where they were not compatible and were still successful was in their embedded line which was originally the 8748 (which became the 8051). I suppose it also can be pointed out that the 860/960 ended up have a fairly long life also in the embedded space and were "successful" there. But those ISAs were eventually EOL’s; while you can still find 8051 ISA based chips being manufactured today. Others in this list seem to object to the fact the current INTEL*64 ISA is owned and defined by Intel, not by a competing firm who originally created an extension to the x86 (ney IA-32) ISA before Intel and brought it to market in their product line. Fair enough and I personally think I understand why people might believe that and I do understand and lived the same history. But I point out that it does not change the fact that Intel owns and defines ISA, it >>is<< Intel’s ISA. Someone else does not get to call it something else when they do not own it. Just as the PDP-11, Vax & Alpha were DEC’s ISAs and S360, S/370 & Power is/was IBM’s. Think about 2 other instances, Cal Data extended the PDP-11 before DEC did and Amdahl the S/360 before IBM. As it turns out, DEC sued and put Cal Data out of business but IBM let Amdahl be. In both cases features first pioneered on those other product lines, end up in the original (although maybe with a different name and/or different implementation). But the ISA stayed S/360 and PDP-11 and the owners of each further extended their ISA along the way (S/370, now zSeries, PDP-11 begat VAX 11/780). I ask you for a minute to consider this set of facts. When the engineers at Intel did decide to extend IA32 to 64 bits (which was after others had done it), the Intel engineering team could have created a set of extensions to the x86 family that was different from others currently on the market. We can all guess, but none of us on this list or elsewhere will ever know if taking that design choice would have been successful -- as that choice was made 15 years ago. I think we might agree that a good bit of chaos would have been brought to us as programmers. Instead, the Intel engineers started with an existing set of extensions, and added too (and continued to add too) that list. Intel has brought out many devices since that time and the market has moved on. The choices made by the Intel team does not lessen or make greater the work done by Intel or it’s competitors. It is what it is. I believe that what matters to us as programmers, is that our code runs on those devices – *that they are compatible *- the topic of this discussion. That is to say, I am happy a different path was not chosen. It certainly made my own choices simpler. For the record, the main system I run at home as “ccc.com” happens to be on an Opteron and have no reason to change it. It has a good bit of SCSI storage on it, as well a number of different types of tapes. It “just works” and OpenBSD runs fine “out of the box”.The truth is if I changed it, I’m probably more likely to switch to an unused Tru64 based DS10 with an Alpha in it than an Intel processor because I have one in the basement that is currently turned off. However, that system does not have as many fr
Re: [Simh] VAX/VMS
Clem, I'm in a way not surprised that Intel pretends it invented and owns this, but I'm a bit sad if you do not acknowledge history. But maybe you cannot because of company policy or something. What do I know? However, noone in a sane state of mind believes that Intel invented the 64 bit extensions to the x86. The truth is well known, and you can read up on it from Wikipedia, or why not just read the original AMD specification from 2000. (https://en.wikipedia.org/wiki/X86-64, https://en.wikipedia.org/wiki/AMD_K8) Intel was *not* planning to extend the x86 to 64 bits. Intel had a plan for 64 bit computing, and it was called Itanium. However, as we all know, Itanium had problems, and was slow to the market (and was not delivering on the performance promises either). Meanwhile AMD decided to do a 64 bit extension to the x86 instead, and got that to the market, and customers loved it. Pretty much all larger companies had committed to Itanium, but once AMD pushed their 64 bit x86 out, companies started to falter, and one after another, they dumped their Itanium plans, until only HP was left (which is where we are today). Meanwhile everybody was jumping on the x86-64 bandwagon, and Intel also realized they needed to be there. Yes, Intel owns the "Intel 64" name. Who cares? Noone uses that name (well, maybe except for Intel). Intel didn't even call it "Intel 64" from the start. Earlier they used the names "IA-32e" and "EM64T". AMD owns the "AMD64" name. Few uses that name either. Most people just call it "x86-64", or "x64". The first processor released that implemented the x86-64 instruction set was the AMD K8. Yes, additional extensions have been done to the instruction set since, but they are extensions, not changes. The latest Intel processors can still run the code that is compiled for the AMD K8. For a more complete list of some details that do differ, see https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64. The truth is that for common people, the differences are irrelevant, and more feel like political bickering, and ways of being able to say "we did not copy the AMD solution", while in reality they did. Like I said, the AMD K8 was first, and a program written for that processor will in reality run also on the latest Intel processor. Intel didn't choose that the "Intel 64" should be backwards compatible. It was already decided. Intel itself had already chosen an incompatible way forward - the Itanium. The "Intel 64" was merely Intel's copy of the AMD64. We, the consumers, benefited (well, maybe) from the fact that AMD decided to do a backward compatible 64-bit extension to the x86. And that Intel picked that up (and sortof gave up on the Itanium, even if that one is taking a long time to die. But it's getting close now...) Anyway, that's that. As far as compatibility goes, like we both said, Intel have been ensuring backward compatibility all along. Anyone who claims/blame them for not doing that just don't know what they are talking about. (Unless we talk about when Intel knowingly have not been backward compatible, but that is ok. The Itanium was not meant to be backwards compatible, nor was the iAPX432, i860 or i960, but all have failed. But that's a different story.) Johnny On 2016-02-17 15:20, Clem Cole wrote: For whatever it is worth, this was a discussion about compatibility. My point was and is, Intel owns the trademark; and defines / continues to extend the INTEL*64 and IA-32 ISA's. The current definition can be found at: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html Intel has invested heavily in the ability to moved customer codes from 4004 to today's Phi ISA and IMO, done an excellent job of it. Certainly from the 386 family and later. As Johnny and I both said, you can run MS-DOS and old DOS programs on my current system from an Edison (IoT) module that costs a few dollars all the way up to a world largest supercomputer (the Milky Way 2 system in China) - which is a bit of a frightening thought to me. As Tim points out, the cost to do that compatibility is huge on the development / investment side. As I said, the on-die tax has been reported to me my my brethren as about 5 %. So coming back to compatibility, when the first processors to support INTEL*64 were created, Intel's engineering team had a choice. What is interesting is that Intel's engineers chose to ensure that current set of applications codes continued to run. They did not have too. We might have had two completely different instruction sets if they had chosen otherwise. I personally think, we as consumers won because of that. IMO: I think that would have been a bad thing for developers because a number of choices would need to be made and confusion would have likely arisen. That said, if you look at Apple's use of Fat Binaries, it might have been manageable if Linux and Windows
Re: [Simh] VAX/VMS
On Wed, Feb 17, 2016 at 9:20 AM, Clem Cole wrote: > For whatever it is worth, this was a discussion about compatibility. My > point was and is, Intel owns the trademark; and defines / continues to > extend the INTEL*64 and IA-32 ISA's. The current definition can be found > at: > > http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html > > Intel has invested heavily in the ability to moved customer codes from > 4004 to today's Phi ISA and IMO, done an excellent job of it. Certainly > from the 386 family and later. As Johnny and I both said, you can run > MS-DOS and old DOS programs on my current system from an Edison (IoT) > module that costs a few dollars all the way up to a world largest > supercomputer (the Milky Way 2 system in China) - which is a bit of a > frightening thought to me. > > Can you run it on a Xeon Phi (eg, a 5110P coprocessor card)? > So coming back to compatibility, when the first processors to support > INTEL*64 were created, Intel's engineering team had a choice. What is > interesting is that Intel's engineers chose to ensure that current set of > applications codes continued to run. They did not have too. We might > have had two completely different instruction sets if they had chosen > otherwise. I personally think, we as consumers won because of that. > > However, AMD developed and implemented the first 64-bit extensions to Intel's 32-bit "x86" (Intel 32 if you prefer) instruction set. Also, Intel (given a choice) had two incompatible instruction sets. The common 32-bit x86 ISA, and the Itanium 64-bit ISA. I have several machines with Intel's first 64-bit attempt at an instruction set in it (well, actually the Itanium 2, but you get the idea). Xeon Phi (as currently available) is also only *mostly* compatible with x86 code. The difficulty I've had to get a standalone Linux kernel to compile and run (or even build a working generic version of gcc for it) on the 31S1s that I've got at home are pretty good proof that it's not quite backwards compatible... as noted in Intel's own documentation: "Knights Corner is not completely binary compatible with any previous Intel processor. " ( https://software.intel.com/en-us/blogs/2012/06/05/knights-corner-micro-architecture-support/ ) Pat ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Your opinions do coincide highly with your employer's :) Give credit where credit is due: AMD was the one that expanded the instruction set so you could run all of your IA-32 applications and 64-bit apps at the same time without the use of emulators or bolting another core onto the die...which is what Intel did with Itanium. Intel was busy pushing IA-64 (Itanium) as the future and when AMD released the AMD64 extensions, it took Intel 4 years to release an implementation. Intel has expanded the instruction set since then (as has AMD), which is a good thing, but it was AMD that set us on this course. Brian On 02/17/2016 09:20 AM, Clem Cole wrote: For whatever it is worth, this was a discussion about compatibility. My point was and is, Intel owns the trademark; and defines / continues to extend the INTEL*64 and IA-32 ISA's. The current definition can be found at: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html Intel has invested heavily in the ability to moved customer codes from 4004 to today's Phi ISA and IMO, done an excellent job of it. Certainly from the 386 family and later. As Johnny and I both said, you can run MS-DOS and old DOS programs on my current system from an Edison (IoT) module that costs a few dollars all the way up to a world largest supercomputer (the Milky Way 2 system in China) - which is a bit of a frightening thought to me. As Tim points out, the cost to do that compatibility is huge on the development / investment side. As I said, the on-die tax has been reported to me my my brethren as about 5 %. So coming back to compatibility, when the first processors to support INTEL*64 were created, Intel's engineering team had a choice. What is interesting is that Intel's engineers chose to ensure that current set of applications codes continued to run. They did not have too. We might have had two completely different instruction sets if they had chosen otherwise. I personally think, we as consumers won because of that. IMO: I think that would have been a bad thing for developers because a number of choices would need to be made and confusion would have likely arisen. That said, if you look at Apple's use of Fat Binaries, it might have been manageable if Linux and Windows had done something like that and the different compilers generated code that way. As it turns out, that is not so far fetched, since we are doing that today for Phi, but the difference is that Intel owns both definitions and builds a single set of development tools so that the differences to user is unseen. Frankly, I'm personally glad that the folks that made decision took the path of starting with an existing set of extensions. But that was 10-15 years ago. Intel has continued to extend the ISA since that time and I believe that we will see that going on into the future. As I said, we already see more extensions with the Phi product line. But back to my point, a pure core binary programs will run on a Phi, although today, Phi programs will need to be emulated on Core (until such time as the Phi features and extensions make it into the primary ISA). Will that happen? I can not say, but given the history of Intel, I would suspect it might because compatibility has been something Intel has heavily invested. I probably should add in all of these comments, they are my own and not necessarily those of my employer. That said, I openly point out that I'm a Sr. Architect in the HPC team @ Intel. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
For whatever it is worth, this was a discussion about compatibility. My point was and is, Intel owns the trademark; and defines / continues to extend the INTEL*64 and IA-32 ISA's. The current definition can be found at: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html Intel has invested heavily in the ability to moved customer codes from 4004 to today's Phi ISA and IMO, done an excellent job of it. Certainly from the 386 family and later. As Johnny and I both said, you can run MS-DOS and old DOS programs on my current system from an Edison (IoT) module that costs a few dollars all the way up to a world largest supercomputer (the Milky Way 2 system in China) - which is a bit of a frightening thought to me. As Tim points out, the cost to do that compatibility is huge on the development / investment side. As I said, the on-die tax has been reported to me my my brethren as about 5 %. So coming back to compatibility, when the first processors to support INTEL*64 were created, Intel's engineering team had a choice. What is interesting is that Intel's engineers chose to ensure that current set of applications codes continued to run. They did not have too. We might have had two completely different instruction sets if they had chosen otherwise. I personally think, we as consumers won because of that. IMO: I think that would have been a bad thing for developers because a number of choices would need to be made and confusion would have likely arisen. That said, if you look at Apple's use of Fat Binaries, it might have been manageable if Linux and Windows had done something like that and the different compilers generated code that way. As it turns out, that is not so far fetched, since we are doing that today for Phi, but the difference is that Intel owns both definitions and builds a single set of development tools so that the differences to user is unseen. Frankly, I'm personally glad that the folks that made decision took the path of starting with an existing set of extensions. But that was 10-15 years ago. Intel has continued to extend the ISA since that time and I believe that we will see that going on into the future. As I said, we already see more extensions with the Phi product line.But back to my point, a pure core binary programs will run on a Phi, although today, Phi programs will need to be emulated on Core (until such time as the Phi features and extensions make it into the primary ISA). Will that happen? I can not say, but given the history of Intel, I would suspect it might because compatibility has been something Intel has heavily invested. I probably should add in all of these comments, they are my own and not necessarily those of my employer. That said, I openly point out that I'm a Sr. Architect in the HPC team @ Intel. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
That is a pretty Intel centric view of history. The original architecture was developed by AMD. The architecture was initially called x86-64 by AMD and was renamed right before the public launch to AMD64. SUSE was involved in the development of the gcc port and linux port, didn’t wan’t to take the risk of of changing all of the x86_64 references to amd64, so the x86_64 name persists. The first Intel chips got a number of items wrong that were never issues on the released AMD chips. The NX bit was not in all of AMD’s development spins, but was discussed publicly on the x86_64 mailing list prior to the release of the first Athlon64 chips. When Intel later released their first x86_64 compatible chips they did not include the NX bit and would not run Linux correctly. Microsoft, having early access to the Intel chips, did not have issues with the 64-bit version of Windows as I recall. Both Intel and AMD have made enhancements over the years to the AMD64 (ne x86_64) architecture. The AMD and Intel flavors of virtualization support are different, AMD’s Pacifica is well thought out, Intel took four iterations on Virtualization to get to what they have today. Because of the quick response on the Intel side, they were able to stay competitive in the marketplace. If they had continued to pursue the Itanium route for 64-bit, they would ultimately have lost the market to AMD. Fortunately for Intel, they included enough AMD compatibility to remain competitive. They had huge advantages on the semiconductors side of the house, that has allowed them to be the dominate player that they are today. — TJ > On Feb 16, 2016, at 2:44 PM, Clement T. Cole wrote: > > Depends on how you look at it, AMD did developed an early 64 bit extensions > on to the 32 bit ISA. But that was over 10 years ago and I was not there at > the time. IMO thankfully when Core/INTEL*64 was developed much of it made > to be the same in the desire to keep user binaries to run. Since that time > Intel has taken and continues to extend the ISA. Simply put, INTEL*64 is > different - there are whole sections of the ISA that are not implemented on > all processors (even at Intel). For instance Intel's Phi brings in a number > of new instructions. INTEL*64 is the official name (trademark name) for the > ISA (although some folks refuse to acknowledge that fact). > > Also in the case of privileged ISA features there are some significant > difference which the OS's have to handle. For instance the VT subsystems > have some differences. > > As Tim points out the real cost of compatibly is the architectural tests > suites and effort to ensure that things just work across the board. In the > case of x86 it's even more difficult then just the instructions and BIOS > because it means whole HW sections have to be made virtual also so that old > code (like ones for DOS) do keep working. > > Similarly, Regardless of which Intel produced processor for that ISA is the > output target, > Intel's compilers generate code for the INTEL*64 ISA and perform optimization > for same. When user mode binaries are run on non-intel manufactured > processors they should "just work" if the others manufactures have > implemented equivalent functionality (There is no truth to the sometimes > stated comment that Intel's compilers check for non-intel manufactured and do > bad things). That said the Intel development suite does not do specific > optimizations for non intel manufactured processors but they do make an > attempt to ensure things execute correctly. > > The neutral term is x86_64 which does not acknowledge either AMD or Intel. > But in print, I am fairly certain that the ISA's trademarked name is INTEL*64 > when referring to that ISA. > > Sent from my iPad > >> On Feb 16, 2016, at 5:02 PM, Rhialto wrote: >> >>> On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote: >>> Unless you are using a cell phone, I'm willing to bet that you are typing >>> your messages on a INTEL*64 architecture system, even if the processor is >>> not made by Intel. >> >> Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64 >> after all... >> >> -Olaf. >> -- >> ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for >> \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Depends on how you look at it, AMD did developed an early 64 bit extensions on to the 32 bit ISA. But that was over 10 years ago and I was not there at the time. IMO thankfully when Core/INTEL*64 was developed much of it made to be the same in the desire to keep user binaries to run. Since that time Intel has taken and continues to extend the ISA. Simply put, INTEL*64 is different - there are whole sections of the ISA that are not implemented on all processors (even at Intel). For instance Intel's Phi brings in a number of new instructions. INTEL*64 is the official name (trademark name) for the ISA (although some folks refuse to acknowledge that fact). Also in the case of privileged ISA features there are some significant difference which the OS's have to handle. For instance the VT subsystems have some differences. As Tim points out the real cost of compatibly is the architectural tests suites and effort to ensure that things just work across the board. In the case of x86 it's even more difficult then just the instructions and BIOS because it means whole HW sections have to be made virtual also so that old code (like ones for DOS) do keep working. Similarly, Regardless of which Intel produced processor for that ISA is the output target, Intel's compilers generate code for the INTEL*64 ISA and perform optimization for same. When user mode binaries are run on non-intel manufactured processors they should "just work" if the others manufactures have implemented equivalent functionality (There is no truth to the sometimes stated comment that Intel's compilers check for non-intel manufactured and do bad things). That said the Intel development suite does not do specific optimizations for non intel manufactured processors but they do make an attempt to ensure things execute correctly. The neutral term is x86_64 which does not acknowledge either AMD or Intel. But in print, I am fairly certain that the ISA's trademarked name is INTEL*64 when referring to that ISA. Sent from my iPad > On Feb 16, 2016, at 5:02 PM, Rhialto wrote: > >> On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote: >> Unless you are using a cell phone, I'm willing to bet that you are typing >> your messages on a INTEL*64 architecture system, even if the processor is >> not made by Intel. > > Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64 > after all... > > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for > \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue 16 Feb 2016 at 15:56:05 -0500, Paul Koning wrote: > Amazing. 974 pages, 131 claims. And yes, a long listing of > microcode. And flow charts. And schematics. It clearly is a 360. I leafed through the American version, and the UK one is twice the size! It even includes a binary microcode dump with comments (or maybe it's a listing from a microcode assembler). The flowcharts are "more readable" though. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote: > Unless you are using a cell phone, I'm willing to bet that you are typing > your messages on a INTEL*64 architecture system, even if the processor is > not made by Intel. Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64 after all... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> On Feb 16, 2016, at 2:58 PM, Rhialto wrote: > > On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote: >> Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and >> it's brother MTS, both rely on it. The 67 is a Model 65 with a Data >> Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which >> is in a cabinet that t'ed off the main CPU and is about the same size en >> entire Vax 780 which would follow 10 years later. > > Note that I have rescued at some point in the past an IBM patent (it was > the UK version) of a computer with microcode, and maybe Virtual Memory > too. Although they didn't call it that I think. After reading, it > described something remarkably like the S/360. It lists the full > microcode and has extensive hardware schematics. > > The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al. > USA patent application number 357372, 6 April 1964. The issued patent > number is US003400371. Amazing. 974 pages, 131 claims. And yes, a long listing of microcode. And flow charts. And schematics. It clearly is a 360. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> -Original Message- > From: Rhialto [mailto:rhia...@falu.nl] > Sent: 16 February 2016 19:58 > To: Clem Cole > Cc: Dave Wade ; SIMH > Subject: Re: [Simh] VAX/VMS > > On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote: > > Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and > > it's brother MTS, both rely on it. The 67 is a Model 65 with a Data > > Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB > > which is in a cabinet that t'ed off the main CPU and is about the same > > size en entire Vax 780 which would follow 10 years later. > > Note that I have rescued at some point in the past an IBM patent (it was the > UK version) of a computer with microcode, and maybe Virtual Memory too. > Although they didn't call it that I think. After reading, it described something Perhaps relocation. Allows code to run from any start address. Also storage keys which allow memory to be protected. Virtual Memory was first patented by Manchester University and implemented in Atlas. I believe IBM later acquired this patent. There are many later patents for virtual memory improvements. > remarkably like the S/360. It lists the full microcode and has extensive > hardware schematics. > > The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al. > USA patent application number 357372, 6 April 1964. The issued patent > number is US003400371. > I believe that Amdahl (as a company) also came up with the patent for a control processor ... so IBM paid them for every mainframe with a control processor, and Amdahl paid IBM for the Virtual Memory Patents... > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for > \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' Dave G4UGM ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote: > Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and > it's brother MTS, both rely on it. The 67 is a Model 65 with a Data > Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which > is in a cabinet that t'ed off the main CPU and is about the same size en > entire Vax 780 which would follow 10 years later. Note that I have rescued at some point in the past an IBM patent (it was the UK version) of a computer with microcode, and maybe Virtual Memory too. Although they didn't call it that I think. After reading, it described something remarkably like the S/360. It lists the full microcode and has extensive hardware schematics. The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al. USA patent application number 357372, 6 April 1964. The issued patent number is US003400371. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 16-Feb-16 12:12, li...@openmailbox.org wrote: > On Tue, 16 Feb 2016 11:52:17 -0500 > Paul Koning wrote: > >>> On Feb 16, 2016, at 9:56 AM, Timothe Litt wrote: >>> >>> ... >>> Nonetheless, Brooks (@IBM) definitely gets credit for the first >>> commercial line of architecturally (forward) compatible machines. Prior >>> to that inspiration, every new machine was unique and most software >>> started over (including compilers). >> I'm not sure that "first" is accurate. If in the sense of a series of >> machines for which that feature is specifically marketed, perhaps. But >> the PDP4/7/9/15 is another example that started somewhat earlier. (PDP1 >> doesn't quite match, as I understand it.) CDC 6000 series definitely >> fits your definition, and those came out at the same time as the 360. >> The Burroughs B5000 series is somewhat older (1961, says Wikipedia). > More correctly we should say the IBM S/360 was the first series of > computers to be designed around an architecture so that the smallest and > largest models in the lineup were all architecturally identical (mostly!) > and that could all run the same OS (mostly). The upward compatibility came > later, but was enabled by a lot of sound architecture decisions including > one design regardless of capacity. > >> Of all those, the IBM 360 descendants are perhaps the most commercially >> successful, and also probably the longest lived. > Not perhaps or probably, but certainly. > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh If you're going to use a generic address like "li...@openmailbox.org", please add a name comment (e.g. "Fred Brooks" ) and/or a signature. Everyone else makes it clear who they are Thanks. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, 16 Feb 2016 11:52:17 -0500 Paul Koning wrote: > > > On Feb 16, 2016, at 9:56 AM, Timothe Litt wrote: > > > > ... > > Nonetheless, Brooks (@IBM) definitely gets credit for the first > > commercial line of architecturally (forward) compatible machines. Prior > > to that inspiration, every new machine was unique and most software > > started over (including compilers). > > I'm not sure that "first" is accurate. If in the sense of a series of > machines for which that feature is specifically marketed, perhaps. But > the PDP4/7/9/15 is another example that started somewhat earlier. (PDP1 > doesn't quite match, as I understand it.) CDC 6000 series definitely > fits your definition, and those came out at the same time as the 360. > The Burroughs B5000 series is somewhat older (1961, says Wikipedia). More correctly we should say the IBM S/360 was the first series of computers to be designed around an architecture so that the smallest and largest models in the lineup were all architecturally identical (mostly!) and that could all run the same OS (mostly). The upward compatibility came later, but was enabled by a lot of sound architecture decisions including one design regardless of capacity. > Of all those, the IBM 360 descendants are perhaps the most commercially > successful, and also probably the longest lived. Not perhaps or probably, but certainly. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> On Feb 16, 2016, at 9:56 AM, Timothe Litt wrote: > > ... > Nonetheless, Brooks (@IBM) definitely gets credit for the first > commercial line of architecturally (forward) compatible machines. Prior > to that inspiration, every new machine was unique and most software > started over (including compilers). I'm not sure that "first" is accurate. If in the sense of a series of machines for which that feature is specifically marketed, perhaps. But the PDP4/7/9/15 is another example that started somewhat earlier. (PDP1 doesn't quite match, as I understand it.) CDC 6000 series definitely fits your definition, and those came out at the same time as the 360. The Burroughs B5000 series is somewhat older (1961, says Wikipedia). Not as well known and perhaps not quite close enough to be called "forward compatible" are the Electrologica EL-X1 (1958) and EL-X8 (1964), with more planned but not shipped before the company was bought & closed down. Of all those, the IBM 360 descendants are perhaps the most commercially successful, and also probably the longest lived. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 17:25, Clem Cole wrote: On Tue, Feb 16, 2016 at 10:54 AM, mailto:li...@openmailbox.org>> wrote: Every new IBM machine and OS was designed to preserve the investment in all the software and development skills the customer already had. In terms of architectural and implementation purity with compatability as a fundamental principle and a 52 year track record of success, IBM wrote the book. I agree, but I suggest that you don't sell Intel short. To be honest, I used to think the folks @ Intel had to be brain dead until I thought it about and looked more carefully. Once I started to work for them, I really understood. They deal with with an ugly architecture, but they make the best of it for their customers. You are right Intel killed compatibility many times between lots of different impure attempts ( 432, all of their RISC systems etc...), but to Intel's credit - they always did a good enough job on compatibility in the 4004-8080-8086-80386-INTEL*64 transitions to move the customers programs over somehow (again you are right, sometimes easier than others). But the trick is that economics of the Intel family, along with compatibility - drove the price of computing down. And Intel was compatible enough to have people keep doing it. The fact is you can still boot and old copy of DOS and the programs will run. As was brought up in this thread, if you take the last VAX made it will not boot VMS 1.x and I suspect it will not even run user code compiled for it for any really sophisticated user code. More over before DOS, Intel (while hardly perfect) did manage to bring 8080 programs to 8086 systems (and 4004 to 8008 and 8008 to 8080). Yes, IBM and DEC did it better than Intel did early on and on many threads, but over the long haul of their flagship architecture, stuff just works. The bottom line is ugly as it may be, Intel did, does it and the ecosystem for their compatible architecture is frankly worth a great deal more than S/360 or anything DEC did. The economics puts Intel in the leadership position here. You can agree or not, but my point is not that 8080/x86/INTEL*64 is a great architecture (it is not); but that Intel has done an incredible job of moving it forward, with binaries continuing to "just work" and all while dropping the price all the time. Unless you are using a cell phone, I'm willing to bet that you are typing your messages on a INTEL*64 architecture system, even if the processor is not made by Intel. I agree with all Clem wrote here. Intel can't be blamed for the effort in keeping compatibility working. It does work. However, maybe Intel is not to credit for this (or at least not fully), sine the x86-64 is actually a creation from AMD. Intel was trying to kill the product by introducing the incompatible Itanium. AMD showed that it was feasible to extend the old pig to 64 bits, and the market went with them. In a way, Intel is trapped by its own success. Nothing can replace the x86, no matter how ugly the architecture is. The point is, that any new CPUs needs to be backwards compatible all the way to the 8088, or else they will not fly. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, 16 Feb 2016 11:25:37 -0500 Clem Cole wrote: > Unless you are using a cell phone, I'm willing to bet that you are typing > your messages on a INTEL*64 architecture system, even if the processor is > not made by Intel. Nope! Sun Blade! ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, Feb 16, 2016 at 10:54 AM, wrote: > Every new IBM machine and OS was designed to preserve the investment in all > > the software and development skills the customer already had. In terms of > > architectural and implementation purity with compatability as a fundamental > principle and a 52 year track record of success, IBM wrote the book. > I agree, but I suggest that you don't sell Intel short. To be honest, I used to think the folks @ Intel had to be brain dead until I thought it about and looked more carefully. Once I started to work for them, I really understood. They deal with with an ugly architecture, but they make the best of it for their customers. You are right Intel killed compatibility many times between lots of different impure attempts ( 432, all of their RISC systems etc...), but to Intel's credit - they always did a good enough job on compatibility in the 4004-8080-8086-80386-INTEL*64 transitions to move the customers programs over somehow (again you are right, sometimes easier than others). But the trick is that economics of the Intel family, along with compatibility - drove the price of computing down. And Intel was compatible enough to have people keep doing it. The fact is you can still boot and old copy of DOS and the programs will run. As was brought up in this thread, if you take the last VAX made it will not boot VMS 1.x and I suspect it will not even run user code compiled for it for any really sophisticated user code. More over before DOS, Intel (while hardly perfect) did manage to bring 8080 programs to 8086 systems (and 4004 to 8008 and 8008 to 8080). Yes, IBM and DEC did it better than Intel did early on and on many threads, but over the long haul of their flagship architecture, stuff just works. The bottom line is ugly as it may be, Intel did, does it and the ecosystem for their compatible architecture is frankly worth a great deal more than S/360 or anything DEC did. The economics puts Intel in the leadership position here. You can agree or not, but my point is not that 8080/x86/INTEL*64 is a great architecture (it is not); but that Intel has done an incredible job of moving it forward, with binaries continuing to "just work" and all while dropping the price all the time. Unless you are using a cell phone, I'm willing to bet that you are typing your messages on a INTEL*64 architecture system, even if the processor is not made by Intel. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 16-Feb-16 10:58, li...@openmailbox.org wrote: > On Tue, 16 Feb 2016 10:28:27 -0500 > Clem Cole wrote: > >> The using >> EBCDIC >> instead of >> ASCII >> was a sad thing. IBM had been heavy in development of ASCII and I >> believe even chaired the ANSI committee creating it. In fact if you look >> at marketing literature, S360 was supposed to be the >> first commercial system to support it. But with OS/360 being so late, >> Brooks was said to make the decision to keep the primary code EBCDIC (for >> compatibility). Until the switch to Power years 25+ years later, IBM >> (and its users) would pay that price. > There was no switch to POWER. The very latest z Archicture machines still > use EBCDIC and it has never been an issue. Yeah, we prefer big-endian too. > Not to fan the architecture religious wars, but that's a rather insular point of view. EBCDIC *is* an issue for users outside the IBM sphere. It's a pain for interchange with the rest of the world. The different collating sequence confounds people who expect digits before letters (or vice-versa). Languages end up with different pain points as a result of trying to paper this over. Look at Perl, which is reasonably portable. EBCDIC still trips up library modules regularly. Regular expressions frequently are coded as though ASCII were the only codeset. So are sorts. The few characters in one but not the other are an annoyance - now lessened by Unicode. But that has its own issues. Yes, people in the EBCDIC world learn to code 'properly' to accommodate these difference. People in the rest of the world are regularly tripped-up by them. It's a lot harder to deal with code-set independent coding than portable C. Neither is fun. But at least there are lots more tools for detecting the issues. And few non-IBM development platforms support an EBCDIC locale for people to validate their code - if they are even aware they should care. I knowingly code stuff for myself with alarm bells going off "that won't work for EBCDIC". But I don't care to take the time for code that will "never leave my house". Until it does :-) That's not to say that one codeset is better than the other. At one time, either was a sane choice between legacy compatibility and technology. IBM made one. Unfortunately, the rest of the world didn't follow IBM. And IBM, for sensible business, if not technical reasons stuck with its choice. Today, there still is pain. It's not which one is 'better'. It's that they're *different*. Unicode has its own coding and migration issues. But at least within the UTF-8 subset, your collating sequence doesn't change. And you can bring in applications without a porting effort. I'm endian-neutral. I like bit 0 always being a sign bit & network compatibility of BE. And I like the easy multi/variable-precision math of LE. I'm also a PDP-10 person - where byte size and codeset are whatever you want. (1-36 bits for the byte size.) And COBOL supported ASCII, EBCDIC and SIXBIT equally as far back as the 70s... As did sort, and tape labels. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 16:54, li...@openmailbox.org wrote: On Tue, 16 Feb 2016 08:58:11 -0500 Clem Cole wrote: As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here.In truth, probably the best of pure compatibility story has to be Intel. No offense, but to even suggest Intel has the best compatibility or that pure and Intel go together in the same sentence is completely over the top. From every angle I can see, Intel has about the worst track record of upward or backward compatibility and the least amount of design integrity or purity of any vendor still in business and probably in the history of modern computing. [...] I think you need to keep the OS and the processor separate in this discussion. As far as I'm aware, you can still boot an old version of MS-DOS on the latest x86-64 based PC you can grab. However, that demands not only that the CPU is backwards compatible (it is), but that you also have a BIOS that is compatible, since MS-DOS depends on that. But there is no point ranting about the upgrades and enhancements to the CPU not being backward compatible. That would never be expected. The crucial question is if you can boot that old OS, and run your old programs. And the answer to that one is, I believe, yes. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 16:16, Dave Wade wrote: I think it is also interesting to compare the Intel architecture which was designed to be economical with Silicon against the M6800, M6809 and the M68000 which were designed to be programmer friendly, and of course note the similarities between the 68000 & S/360 with 16 general purpose registers and orthogonal instruction set) and wonder where we would be today had IBM chosen them for its PC rather than the 8086 which I assume was cheaper… I might be out on a limb here, but I think one reason that IBM went with the 8086 was that Intel could in fact deliver. Motorola had more issues with actually delivering large quantities, in time. Also, the M68000 would be more similar to a PDP-11 or a VAX, I would think, except the fact that the 68000 wasn't as properly orthogonal. It actually have a lot of warts if you start looking closely. Johnny Dave G4UGM *From:*Clem Cole [mailto:cl...@ccc.com] *Sent:* 16 February 2016 13:58 *To:* Dave Wade *Cc:* SIMH *Subject:* Re: [Simh] VAX/VMS Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and it's brother MTS, both rely on it. The 67 is a Model 65 with a Data Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 which would follow 10 years later. Think about that for a minute -- an 8 word TLB. At Intel we regularly examine the different sizes of the different parts of the memory system. Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. Also it is also interesting to consider that while the AT&T folks came off of Multics, a number of us university types that would work on earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is still the only system I ever used that lived in the debugger as your command system - which I always thought was a cool idea. As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here.In truth, probably the best of pure compatibility story has to be Intel. The H/L registers of the 4004 are still there ;-) Seriously, the INTEL*64 is from an computer science standpoint, not an architecture you would create from scratch. But Intel has completely understood the economics of SW compatibility. Also, if you peeked inside a modern processor, you would discover they are dataflow engines and put together with all of the modern computer science; but there is about a 5% silicon tax paid for compatibility. Clearly, my siblings at Intel believe it's worth tax and the customers seem to keep wanting it. Clem On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade mailto:dave.g4...@gmail.com>> wrote: > -Original Message- > From: Simh [mailto:simh-boun...@trailing-edge.com <mailto:simh-boun...@trailing-edge.com>] On Behalf Of Wilm > Boerhout > Sent: 16 February 2016 11:58 > To: simh@trailing-edge.com <mailto:simh@trailing-edge.com> > Subject: Re: [Simh] VAX/VMS > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen S/360 compatibility is only forward, and only to a certain point. S/360 and S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has Virtual Memory as standard. Then came the "great divide" S/370XA. XA mode has 31-bit addressing and different I/O instructions. Some of the XA boxes will work is S/370 mode, but many won't. More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit mode but more recent boxes need a 64-bit OS. So the earliest incarnations of "OS", which were I guess "MFT" which is basically a fixed number of partitions will run on later machines until you get to systems which will only run in 31bit mode. (XA Mode). OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid for version) will only run on S/370 or later, not on 360, as they need Virtual Memory and it stops working at the same point as MFT when 31 bit only machines appear. There are also issues of Virtual Memory Page size which may stop MVS (the free ver
Re: [Simh] VAX/VMS
On Tue, 16 Feb 2016 10:28:27 -0500 Clem Cole wrote: > The using > EBCDIC > instead of > ASCII > was a sad thing. IBM had been heavy in development of ASCII and I > believe even chaired the ANSI committee creating it. In fact if you look > at marketing literature, S360 was supposed to be the > first commercial system to support it. But with OS/360 being so late, > Brooks was said to make the decision to keep the primary code EBCDIC (for > compatibility). Until the switch to Power years 25+ years later, IBM > (and its users) would pay that price. There was no switch to POWER. The very latest z Archicture machines still use EBCDIC and it has never been an issue. Yeah, we prefer big-endian too. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, 16 Feb 2016 08:58:11 -0500 Clem Cole wrote: > As for what started this thread. I think it is interesting that the long > term successful architectures in the market did have a excellent > compatibility stories. IBM with system 360 certainly set a high bar, and > DEC has nothing to be ashamed of, the different DEC lines, particularly > the Vax, did a great job here.In truth, probably the best of pure > compatibility story has to be Intel. No offense, but to even suggest Intel has the best compatibility or that pure and Intel go together in the same sentence is completely over the top. From every angle I can see, Intel has about the worst track record of upward or backward compatibility and the least amount of design integrity or purity of any vendor still in business and probably in the history of modern computing. The basic architecture of S/360 from 1964 is still being used and developed today, and as Dave pointed out the very latest OS and hardware still run object code from that period. It is not uncommon for thirty plus year old software systems to be running today on the latest platform. Where is there anything even remotely comparable to that on Intel? Backwards compatibility for IBM? No. That was not a priority, quite the contrary. IBM was always a hardware company until the later years. They sold hardware that preserved your software and development investment. New OS won't run on old hardware and that is by design. > The H/L registers of the 4004 are still there ;-) All the registers from OS/360 are still there too. The difference is IBM code from those days still runs today. IBM preserved the investment by making sure all the applications and most of the systems software that was ever written will run as long as you want to run it. How many apps from the 4004 or 8080 days will even run on an old copy of Windows XP from Year 2000? Intel broke compatability at almost every step of the way, real mode to protected mode, the list goes on. All the investment people had in DOS realmode apps and development and everything prior to that basically went into the trash bin. Why the API bork between x86 and x86_64? The linkage conventions in IBM land haven't changed since OS/360. Sure, there are new and better ways to do things but the old ways still work too. Why not on Intel? Why can't I link a 32 bit executable with a 64 bit executable on Intel? Yes, I know about X32 but there isn't any OS using it and it was too little too late. Even with their billions of dollars in R&D Intel couldn't get a 64 bit chip out the door, they had to rely on AMD to do it. Why do I need two copies of libraries if I want to run 32 bit and 64 bit code in the same OS? We don't with IBM. Why does a piece of Intel code that runs 64 bit need twice the footprint of a 32 bit piece of code? It doesn't on an IBM machine. Why were the BCD instructions removed in 64 bit mode? Especially since you can't change modes in one program on Intel, and since you can't invoke a 32 bit piece of code from a 64 bit piece of code on Intel, or vice versa, how could they remove instructions that used to work? That's compatibility? I have stayed away from Intel in my career as much as I could but even I am aware of these problems. I'm sure people who know could point out a lot more. These are all problems that never even happened with IBM. IBM boxes can run 24 bit, 31 bit, and 64 bit mode apps all in one OS, with one set of libraries, no relinking. We can link 24 bit, 31 bit, and 64 bit addressing mode code in one executable. We can switch modes within one application, from one line of code to the next. Instructions didn't become obsolete or disappear as the architecture evolved and generally every instruction is available in every mode. There is no automatic footprint increase between executables running in 24 bit mode to those running in 64 bit mode. Every new IBM machine and OS was designed to preserve the investment in all the software and development skills the customer already had. In terms of architectural and implementation purity with compatability as a fundamental principle and a 52 year track record of success, IBM wrote the book. And they're still going strong. You'll need a big glue gun and a room full of Intel's best chips to come close to getting as much actual work done as you can on one IBM z12 or z13. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, Feb 16, 2016 at 9:56 AM, Timothe Litt wrote: > Nonetheless, Brooks (@IBM) definitely gets credit for the first > > commercial line of architecturally (forward) compatible machines. Prior > > to that inspiration, every new machine was unique and most software > started over (including compilers). > Amen -- I credit Brooks for 3 things good things and one bad Good: 1.) architectural compatibility 2.) a 32 bit word size with an large address space (24 bits in this case) 3.) 8 bit byte Bad: EBCDIC over ASCII I used to work with the Chief Designer of Model 50 at one of my start ups. He had some very interesting stories. Gordon Bell always said the single worst mistake you can make in an architecture is too few address bits. Russ said that the word and bytes sizes that Brooks wanted, Amdahl thought were "wasteful and frivolous" but Brooks one the war. Supposedly Amdahl wanted a 6 bit byte, but Brooks was said to thrown him out of office until he came back with something that was a power of two "that he could program." FWIW: Around the same time, Seymour Cray would use a 6 bit byte at CDC and not embrace 8 bits until the Cray-1 10 years later --- and look at the craziness that their systems had to handle with N different codes - you actually see some of impact in design of Pascal by Wirth years later. The using EBCDIC instead of ASCII was a sad thing. IBM had been heavy in development of ASCII and I believe even chaired the ANSI committee creating it. In fact if you look at marketing literature, S360 was supposed to be the first commercial system to support it. But with OS/360 being so late, Brooks was said to make the decision to keep the primary code EBCDIC (for compatibility). Until the switch to Power years 25+ years later, IBM (and its users) would pay that price. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
I think IBM chose the 8088 over the Motorola offerings because it would be easier for software vendors to port their z80 CPM software to the 808x given the (mostly) same instruction set and the 808x segmented memory looked like a z80’s 64k memory space if you ignored the segment registers. The 8088 was chosen over the 8086 because it was easier (and cheaper) to interface the then common 8 bit peripheral chips. From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dave Wade Sent: Tuesday, February 16, 2016 10:16 AM To: 'Clem Cole' Cc: 'SIMH' Subject: Re: [Simh] VAX/VMS I was deliberately ignoring the 67 (&47) as they were very much “specials”. I cut my teeth on the 360/67 at Newcastle Upon Type under MTS, (and OS/MVT) but MTS was never generally available, MVS and later won’t run on the 360/67, and TSS pretty much died a death. Even CP/47 and CP/67 had a major re-write to become VM/370… The 360/67 actually had 32 bit addressing rather than 31-bit that’s XA and S/390. Also as for comparison with the VAX on memory cabinet which I think had 64K Bytes is about the same size as a large VAX. This is the Newcastle 360/67 with 512K of Core and the DAT gate open… http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.jpg and a close view of the core cabinet here:- http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/21.html I think it is also interesting to compare the Intel architecture which was designed to be economical with Silicon against the M6800, M6809 and the M68000 which were designed to be programmer friendly, and of course note the similarities between the 68000 & S/360 with 16 general purpose registers and orthogonal instruction set) and wonder where we would be today had IBM chosen them for its PC rather than the 8086 which I assume was cheaper… Dave G4UGM From: Clem Cole [mailto:cl...@ccc.com] Sent: 16 February 2016 13:58 To: Dave Wade mailto:dave.g4...@gmail.com>> Cc: SIMH mailto:simh@trailing-edge.com>> Subject: Re: [Simh] VAX/VMS Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and it's brother MTS, both rely on it. The 67 is a Model 65 with a Data Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 which would follow 10 years later. Think about that for a minute -- an 8 word TLB. At Intel we regularly examine the different sizes of the different parts of the memory system. Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. Also it is also interesting to consider that while the AT&T folks came off of Multics, a number of us university types that would work on earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is still the only system I ever used that lived in the debugger as your command system - which I always thought was a cool idea. As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here.In truth, probably the best of pure compatibility story has to be Intel. The H/L registers of the 4004 are still there ;-) Seriously, the INTEL*64 is from an computer science standpoint, not an architecture you would create from scratch. But Intel has completely understood the economics of SW compatibility. Also, if you peeked inside a modern processor, you would discover they are dataflow engines and put together with all of the modern computer science; but there is about a 5% silicon tax paid for compatibility. Clearly, my siblings at Intel believe it's worth tax and the customers seem to keep wanting it. Clem On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade mailto:dave.g4...@gmail.com>> wrote: > -Original Message- > From: Simh > [mailto:simh-boun...@trailing-edge.com<mailto:simh-boun...@trailing-edge.com>] > On Behalf Of Wilm > Boerhout > Sent: 16 February 2016 11:58 > To: simh@trailing-edge.com<mailto:simh@trailing-edge.com> > Subject: Re: [Simh] VAX/VMS > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen S/360 compatibility is only forward, and only to a certain point. S/360 and S/370 are both 24-bit add
Re: [Simh] VAX/VMS
On 16-Feb-16 10:16, Dave Wade wrote: > > I > > > I think it is also interesting to compare the Intel architecture which > was designed to be economical with Silicon against the M6800, M6809 > and the M68000 which were designed to be programmer friendly, and of > course note the similarities between the 68000 & S/360 with 16 general > purpose registers and orthogonal instruction set) and wonder where we > would be today had IBM chosen them for its PC rather than the 8086 > which I assume was cheaper… > > I worked with IBM in Boca Raton at one point. This is where the IBM PC was developed, and I talked with some of the originators. They told me that they considered the 8086, the 68000 & the T11 for the PC. They really, really wanted the -11. IBM had the largest population of -11 programmers in the world at one time. They used the 11 for manufacturing and real-time. There was a huge amount of software. But DEC wouldn't sell the -11 to them. So they went for price and that deal with Gates to write DOS. Neither was supposed to last... smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
I was deliberately ignoring the 67 (&47) as they were very much “specials”. I cut my teeth on the 360/67 at Newcastle Upon Type under MTS, (and OS/MVT) but MTS was never generally available, MVS and later won’t run on the 360/67, and TSS pretty much died a death. Even CP/47 and CP/67 had a major re-write to become VM/370… The 360/67 actually had 32 bit addressing rather than 31-bit that’s XA and S/390. Also as for comparison with the VAX on memory cabinet which I think had 64K Bytes is about the same size as a large VAX. This is the Newcastle 360/67 with 512K of Core and the DAT gate open… http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.jpg and a close view of the core cabinet here:- http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/21.html I think it is also interesting to compare the Intel architecture which was designed to be economical with Silicon against the M6800, M6809 and the M68000 which were designed to be programmer friendly, and of course note the similarities between the 68000 & S/360 with 16 general purpose registers and orthogonal instruction set) and wonder where we would be today had IBM chosen them for its PC rather than the 8086 which I assume was cheaper… Dave G4UGM From: Clem Cole [mailto:cl...@ccc.com] Sent: 16 February 2016 13:58 To: Dave Wade Cc: SIMH Subject: Re: [Simh] VAX/VMS Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and it's brother MTS, both rely on it. The 67 is a Model 65 with a Data Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 which would follow 10 years later. Think about that for a minute -- an 8 word TLB. At Intel we regularly examine the different sizes of the different parts of the memory system. Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. Also it is also interesting to consider that while the AT&T folks came off of Multics, a number of us university types that would work on earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is still the only system I ever used that lived in the debugger as your command system - which I always thought was a cool idea. As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here.In truth, probably the best of pure compatibility story has to be Intel. The H/L registers of the 4004 are still there ;-) Seriously, the INTEL*64 is from an computer science standpoint, not an architecture you would create from scratch. But Intel has completely understood the economics of SW compatibility. Also, if you peeked inside a modern processor, you would discover they are dataflow engines and put together with all of the modern computer science; but there is about a 5% silicon tax paid for compatibility. Clearly, my siblings at Intel believe it's worth tax and the customers seem to keep wanting it. Clem On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade mailto:dave.g4...@gmail.com> > wrote: > -Original Message- > From: Simh [mailto:simh-boun...@trailing-edge.com > <mailto:simh-boun...@trailing-edge.com> ] On Behalf Of Wilm > Boerhout > Sent: 16 February 2016 11:58 > To: simh@trailing-edge.com <mailto:simh@trailing-edge.com> > Subject: Re: [Simh] VAX/VMS > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen S/360 compatibility is only forward, and only to a certain point. S/360 and S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has Virtual Memory as standard. Then came the "great divide" S/370XA. XA mode has 31-bit addressing and different I/O instructions. Some of the XA boxes will work is S/370 mode, but many won't. More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit mode but more recent boxes need a 64-bit OS. So the earliest incarnations of "OS", which were I guess "MFT" which is basically a fixed number of partitions will run on later machines until you get to systems which will only run in 31bit mode. (XA Mode). OS/VS2 and its siblings MVS (This is the fr
Re: [Simh] [SimH] VAX/VMS
On 16-Feb-16 10:10, Bob Supnik wrote: > Okay, I'll bite - what's a VXT1200? I see references to it on Google, > but I can't find a clear description. > It was the X windows terminal. > Tim Litt said rtVAX was never intended to run VMS, but its history is > a bit more complicated. Yes. I described the external effect/story. As usual, you version of the internal details matches my (less precise) memories. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 16-Feb-16 08:58, Clem Cole wrote: > > Also it is also interesting to consider that while the AT&T folks came > off of Multics, a number of us university types that would work on > earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is > still the only system I ever used that lived in the debugger as your > command system - which I always thought was a cool idea. > ITS (MIT PDP-6/10) did that too. I wasn't a frequent user, but the CLI was DDT. > Also, if you peeked inside a modern processor, you would discover they > are dataflow engines and put together with all of the modern computer > science; but there is about a 5% silicon tax paid for compatibility. > Clearly, my siblings at Intel believe it's worth tax and the customers > seem to keep wanting it. 5% is probably fair as as an estimate of silicon area. Actually, the real tax is in processor validation. I worked briefly in that group. It costs more than 5% in manpower to keep making sure that the compatibility modes (yes, 's') work. The older modes have lots of quirks and errata that have to be kept bug-compatible in the face of new implementations. The other taxes are more subtle; things like the memory ordering model and i-stream modification have real performance costs. So does the limited opcode space, which has resulted in ever more opcode prefixing. Intel tries to minimize these with ever increasing cleverness, but they're still there. And probably always will be. Alpha tried to wipe these out with one swell foop, but failed to grok the software costs. (I did point them out at the time, but the general belief was that the migration tools would be good enough and that customers would pay the price for the performance. They weren't, and they didn't.) smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] [SimH] VAX/VMS
Okay, I'll bite - what's a VXT1200? I see references to it on Google, but I can't find a clear description. Tim Litt said rtVAX was never intended to run VMS, but its history is a bit more complicated. The original intent of the uVAX chip program, which kicked off in the spring of 1982, was to establish an chip-and-software industry standard in the IBM PC sense, at the 32b level. The uVAX program office under Roy Moffa had a clearly stated and approved goal to sell uVAX as a chip, a board, and a system, to all comers, with appropriate licensing for VMS. As a result, the definition of the chip was limited in three ways, to minimize the competitive impact on DEC's own products. 1. The chip would implement only a subset of the instructions (also needed to get the microcode to fit). 2. The chip would support only 16MB of physical memory. 3. The chip would have physical system space and physical process page tables. Because of the physical memory limitation, this would limit the size of virtual memory as well. Dave Cutler's MicroVAX I (code name Seahorse) would be even more limited, because it would only support 4MB of physical memory. As the project went on, the software cost of limitation #3 became increasingly clear. In the fall of 1982, Dave Cutler asked that system space be made virtual, with an independent mapping enable bit. The uVAX team wasn't happy about this but eventually agreed. Then, in the spring of 1983, the VMS team concluded that getting VMS to support physical process page tables was really, really hard. Dick Hustvedt asked if full VAX memory management could be supported. Dave was able to do that for MicroVAX I, and after some minimal redesign work, the uVAX team was able to support full memory management as well. But with the virtual memory limitation removed, and evidence that uVAX would perform almost as well as a 780 except on COBOL apps, Ken Olsen became increasingly unhappy about selling the chip and setting up competitors to DEC's own VAX line. In 1984, he reversed the decision to sell the chip but allowed the program to sell boards to continue. Then, on the day of the MicroVAX II system announcement, /at the announcement site/, he reversed the decision about selling boards and had all the OEM material removed from the announcement. The chip and board teams were devastated. In order to have 32b to sell in the real-time market, the real-time business resurrected the original uVAX definition, now to be known as rtVAX. At first, Ken demanded that rtVAX be incapable of running Ultrix/Unix as well, but any changes that prevented that also made it impossible to run VAXELN, Dave Cutler's real-time OS. Eventually, Ken concluded that preventing rtVAX from running VMS was sufficient, and it was allowed to proceed. Because changes had to be confined to microcode, rtVAX included mapped system space and physical process page tables, with a single enable bit. I don't recall if there was a CVAX real-time variant. There's no evidence in the CVAX microcode of alternative memory management flows. The 1987 Semiconductor Handbooks don't mention rtVAX at all. /Bob On 2/16/2016 8:53 AM, simh-requ...@trailing-edge.com wrote: Message: 7 Date: Tue, 16 Feb 2016 14:53:40 +0100 From: Johnny Billquist To:simh@trailing-edge.com Subject: Re: [Simh] VAX/VMS Message-ID:<56c329e4.7090...@softjar.se> Content-Type: text/plain; charset=utf-8; format=flowed On 2016-02-16 13:58, Timothe Litt wrote: >On 16-Feb-16 06:49, Johnny Billquist wrote: >>More precisely, V7.3 will run on*any* VAX, including the primal >>>VAX-11/780. This level of backwards compatibility is unique. >> >>And there are some VAXen on which V7.3 will definitely not run. How >>about rtVAX for example. >Not fair. No version of VMS ever ran on rtVAX - it was designed that >way. (For yes, marketing reasons.) Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm did claim that VMS ran on*any* VAX. I was also tempted to drag up the VXT1200. But since that one does not have the name "VAX" in it, it could perhaps technically be disqualified on that basis... The rtVAX on the other had is without a doubt a VAX, even in name. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 16-Feb-16 08:53, Johnny Billquist wrote: > On 2016-02-16 13:58, Timothe Litt wrote: >> On 16-Feb-16 06:49, Johnny Billquist wrote: >>> More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. >>> >>> And there are some VAXen on which V7.3 will definitely not run. How >>> about rtVAX for example. >> Not fair. No version of VMS ever ran on rtVAX - it was designed that >> way. (For yes, marketing reasons.) > > Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm > did claim that VMS ran on *any* VAX. > I was also tempted to drag up the VXT1200. But since that one does not > have the name "VAX" in it, it could perhaps technically be > disqualified on that basis... The rtVAX on the other had is without a > doubt a VAX, even in name. It would have been more accurate for WIlm to say "any VAX that VMS was ever was released to run on"(1), which is still a strong statement. As pointed out, somewhat stronger than the IBM forward compatibility story. DEC was obsessive about forward and backward compatibility. I even made sure that you could run vectorized programs on a 780. Or SimH (via the OS-delivered transparent instruction emulation.) And the architecture was managed to ensure that there are very few differences at the hardware level for the OS to paper over, even in privileged modes. (Mostly I/O bus evolution and error handling. Not layers of microcode and emulation required by others, including IBM and Intel.) This was also visible in the small effort required to port other VAX OSs (Ultrix, System V, and ELN) , though some of them chose to require kernel builds rather than the VMS approach of loadable kernel modules. Diagnostics were also beneficiaries. And the I/O devices [including disk and network adapters] that used VAXes (rarely rtVAXes, bTW) as embedded controllers. Most of those ran no OS, just a polling/tasking loop. Architecture management was a big effort. It delivered remarkable results. It wasn't free. It did slow innovation. And hardware always had to have a power-up mode that was backward-compatible where that was physically possible. (We didn't insist that you be able to plug an XMI peripheral directly into a 780 Unibus. Though you could have a UBA on a BI on an XMI on a JBox, and aside from a few registers initialized by the OS, your old device driver didn't know the difference.) Inside DEC, the PDP-6/10/20 line made similar guarantees and results. However, the process for accomplishing that was less rigorous. We didn't have the architectural conformance verification infrastructure (e.g. axe, paxe and max) that was developed for VAX from day one. The PDP-11 carried an instruction set forward in the same tradition. Mostly compatibly, but with a lot more user-visible variation. Multiple floating point add-ons and the commercial instruction set. Some instruction oddities, not all intentional. Not to mention memory management variations. It was a *lot* more work for an OS to adapt to a new -11. The VAX architecture process was a reaction to that. The PDP-8 family also provided a lot of compatibility via an ad-hoc process. It, too, had a fair bit of user-visible variation. You could write code that would run on any family member, but it wasn't automatic. With VAX, it is. Nonetheless, Brooks (@IBM) definitely gets credit for the first commercial line of architecturally (forward) compatible machines. Prior to that inspiration, every new machine was unique and most software started over (including compilers). rtVAX *is* architecturally *almost* a VAX. It is listed in the architecture documents as "the rtVAX variant", and was a separate product line. The VAX name, and the ability for user level code (at least in the VAX/ELN supported languages) to run on it were valid technical and marketing features. But you would no more expect VMS to run on ANY rtVAX than you would expect a gasoline-powered auto to run on diesel. Yes, there is a lot of similarity. The engines even look very similar. But the design is explicitly for one or the other. (1) Phrased that way to cover the cases of machines that ran VMS internally at one point, but were killed and the provisional support removed from VMS. (2) As for VXT, I don't remember what it used internally. But there were a couple of versions of that device, and if there was a processor upgrade, its software also benefited from the strong forward and backward compatibility of the VAX. It might have shipped different firmware because of the graphics upgrades or other choices it made. But the processor wouldn't have driven that. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 13:58, Timothe Litt wrote: On 16-Feb-16 06:49, Johnny Billquist wrote: More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. And there are some VAXen on which V7.3 will definitely not run. How about rtVAX for example. Not fair. No version of VMS ever ran on rtVAX - it was designed that way. (For yes, marketing reasons.) Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm did claim that VMS ran on *any* VAX. I was also tempted to drag up the VXT1200. But since that one does not have the name "VAX" in it, it could perhaps technically be disqualified on that basis... The rtVAX on the other had is without a doubt a VAX, even in name. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and it's brother MTS, both rely on it. The 67 is a Model 65 with a Data Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 which would follow 10 years later. Think about that for a minute -- an 8 word TLB. At Intel we regularly examine the different sizes of the different parts of the memory system. Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. Also it is also interesting to consider that while the AT&T folks came off of Multics, a number of us university types that would work on earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is still the only system I ever used that lived in the debugger as your command system - which I always thought was a cool idea. As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here.In truth, probably the best of pure compatibility story has to be Intel. The H/L registers of the 4004 are still there ;-) Seriously, the INTEL*64 is from an computer science standpoint, not an architecture you would create from scratch. But Intel has completely understood the economics of SW compatibility. Also, if you peeked inside a modern processor, you would discover they are dataflow engines and put together with all of the modern computer science; but there is about a 5% silicon tax paid for compatibility. Clearly, my siblings at Intel believe it's worth tax and the customers seem to keep wanting it. Clem On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade wrote: > > -Original Message- > > From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Wilm > > Boerhout > > Sent: 16 February 2016 11:58 > > To: simh@trailing-edge.com > > Subject: Re: [Simh] VAX/VMS > > > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen > > S/360 compatibility is only forward, and only to a certain point. S/360 > and S/370 are both 24-bit addressing and fairly compatible, but S/370 > (Mostly) has Virtual Memory as standard. > > Then came the "great divide" S/370XA. XA mode has 31-bit addressing and > different I/O instructions. Some of the XA boxes will work is S/370 mode, > but many won't. > > More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit > mode but more recent boxes need a 64-bit OS. > > So the earliest incarnations of "OS", which were I guess "MFT" which is > basically a fixed number of partitions will run on later machines until you > get to systems which will only run in 31bit mode. (XA Mode). > > OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid > for version) will only run on S/370 or later, not on 360, as they need > Virtual Memory and it stops working at the same point as MFT when 31 bit > only machines appear. There are also issues of Virtual Memory Page size > which may stop MVS (the free version working) working on some hardware > (there are patches to work round this). > > You also have issues over disk (DASD in IBM speak) support. So whilst MFT > was written for a 1996 S/360 it would in theory run on an P390E from 1996 > so 30 years of computability. However, it would need older disks, which the > P/390E cannot support. > > Of course these changes are really only to do with programs that run in > supervisor state. User mode programs generally will run unchanged from 1966 > through to the present day, and the latest zOS a descendant of MVS will > still run 24-bit applications. I am pretty sure that until a few years > many commercial sites, so mostly Cobol, still used the older "free" > Fortran-66 compiler for the odd Fortran job. > > > > on which V7.3 will definitely not run. How about rtVAX for example. > > > > > I stand corrected. Please note that I had a marketing job once. It > sticks... > > ... I also believe that some of the in-compatibility in IBM kit is to > drive the hardware->software->Hardware->Software upgrade
Re: [Simh] VAX/VMS
On 2016-02-16 14:33, Paul Koning wrote: On Feb 16, 2016, at 6:49 AM, Johnny Billquist wrote: On 2016-02-16 07:57, Wilm Boerhout wrote: Zane Healy schreef op 15-2-2016 om 18:20: [snip] There are plenty of good VAX and VMS manuals out there, including the documentation set. Check eBay and abebooks.com. The last version of VMS that will run on a VAX is v7.3. Zane More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. No, it is not. Talk to IBM about S/360... :-) Nor is it unique at DEC. Consider RT-11. And possibly RSX-11/M (I don't know that one well enough -- does it run on an 11/20?) Yes, unmapped RSX-11M would run on an 11/20. So you could claim that RSX-11M is runnable on almost any PDP-11 ever made. Of course, you would not be able to do program development on all of those platforms, but you could deploy an application. But RSX-11M in some ways feels and behaves rather different if you have an MMU or not. So it would not give the same uniform feeling like VMS or RT-11 would. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 12:57, Wilm Boerhout wrote: Johnny Billquist schreef op 16-2-2016 om 12:49: No, it is not. Talk to IBM about S/360... :-) And there are some VAXen on which V7.3 will definitely not run. How about rtVAX for example. I stand corrected. Please note that I had a marketing job once. It sticks... That's ok. The VAX is still a pretty good example of longevity, compatibility over the line and a generally good design, I think. We don't have to exaggerate, the truth is pretty good as it is. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> On Feb 16, 2016, at 6:49 AM, Johnny Billquist wrote: > > On 2016-02-16 07:57, Wilm Boerhout wrote: >> Zane Healy schreef op 15-2-2016 om 18:20: >> >> [snip] >> >>> There are plenty of good VAX and VMS manuals out there, including the >>> documentation set. Check eBay and abebooks.com. >>> >>> The last version of VMS that will run on a VAX is v7.3. >>> >>> Zane >> More precisely, V7.3 will run on *any* VAX, including the primal >> VAX-11/780. This level of backwards compatibility is unique. > > No, it is not. Talk to IBM about S/360... :-) Nor is it unique at DEC. Consider RT-11. And possibly RSX-11/M (I don't know that one well enough -- does it run on an 11/20?) paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> -Original Message- > From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Wilm > Boerhout > Sent: 16 February 2016 11:58 > To: simh@trailing-edge.com > Subject: Re: [Simh] VAX/VMS > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen S/360 compatibility is only forward, and only to a certain point. S/360 and S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has Virtual Memory as standard. Then came the "great divide" S/370XA. XA mode has 31-bit addressing and different I/O instructions. Some of the XA boxes will work is S/370 mode, but many won't. More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit mode but more recent boxes need a 64-bit OS. So the earliest incarnations of "OS", which were I guess "MFT" which is basically a fixed number of partitions will run on later machines until you get to systems which will only run in 31bit mode. (XA Mode). OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid for version) will only run on S/370 or later, not on 360, as they need Virtual Memory and it stops working at the same point as MFT when 31 bit only machines appear. There are also issues of Virtual Memory Page size which may stop MVS (the free version working) working on some hardware (there are patches to work round this). You also have issues over disk (DASD in IBM speak) support. So whilst MFT was written for a 1996 S/360 it would in theory run on an P390E from 1996 so 30 years of computability. However, it would need older disks, which the P/390E cannot support. Of course these changes are really only to do with programs that run in supervisor state. User mode programs generally will run unchanged from 1966 through to the present day, and the latest zOS a descendant of MVS will still run 24-bit applications. I am pretty sure that until a few years many commercial sites, so mostly Cobol, still used the older "free" Fortran-66 compiler for the odd Fortran job. > > on which V7.3 will definitely not run. How about rtVAX for example. > > > I stand corrected. Please note that I had a marketing job once. It sticks... ... I also believe that some of the in-compatibility in IBM kit is to drive the hardware->software->Hardware->Software upgrade chain and keep the dollars rolling in... Dave G4UGM > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 16-Feb-16 06:49, Johnny Billquist wrote: > More precisely, V7.3 will run on *any* VAX, including the primal >> VAX-11/780. This level of backwards compatibility is unique. > > No, it is not. Talk to IBM about S/360... :-) Agree > And there are some VAXen on which V7.3 will definitely not run. How > about rtVAX for example. Not fair. No version of VMS ever ran on rtVAX - it was designed that way. (For yes, marketing reasons.) Any version of VAX/ELN should run on all previous rtVAXen. For those who don't know, rtVAX is used in the Realtime market. VAX/ELN is the OS used with it. Another Cutler OS - written largely in PASCAL. You build an image on VMS, where it's a layered product. Then deploy to your embedded system, often with a MOP boot. (Yes, another protocol that wireless usually doesn't route.) It is exactly a VAX, except that process page tables are in physical, rather than virtual memory. The difference is that the process base register contains a physical address, and microcode can omit the virtual -> physical translation on a TB refill. This was sold as a performance optimization for Realtime. It was - but it wasn't strictly necessary. It really allowed market differentiation; rtVAX could be sold in embedded systems at an affordable (for the time) price point without cannibalizing the minicomputer/data center machine pricing. (Former DEC Realtime and VAX architect. And no, not responsible for this decision.) smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Johnny Billquist schreef op 16-2-2016 om 12:49: No, it is not. Talk to IBM about S/360... :-) And there are some VAXen on which V7.3 will definitely not run. How about rtVAX for example. I stand corrected. Please note that I had a marketing job once. It sticks... ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 07:57, Wilm Boerhout wrote: Zane Healy schreef op 15-2-2016 om 18:20: [snip] There are plenty of good VAX and VMS manuals out there, including the documentation set. Check eBay and abebooks.com. The last version of VMS that will run on a VAX is v7.3. Zane More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. No, it is not. Talk to IBM about S/360... :-) And there are some VAXen on which V7.3 will definitely not run. How about rtVAX for example. The other way around, each "newer" VAX in general needs a minimum version of VMS to run. Sometimes special "hardware releases" were issued (such as V5.5-H2) to support a new VAX model or variant. Right. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On 2016-02-16 08:18, Ethan Dicks wrote: On Tue, Feb 16, 2016 at 1:57 AM, Wilm Boerhout wrote: More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. I'm sure 7.3 has a very broad list of what it runs on, but (considering I own the hardware in question), does it run on the smallest of the small? VAX-11/725? MicroVAX 2000? The smallest of the small would be the MicroVAX I, and I have a suspicion that it won't run on that machine, but I have not tried... You did mention it in your post, but it really deserves recognition for being a bit more cramped than anything else. As far as VMS demands, I think VMS V6 was more of a hug than V7 is. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Ethan Dicks schreef op 16-2-2016 om 08:18: On Tue, Feb 16, 2016 at 1:57 AM, Wilm Boerhout wrote: More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. I'm sure 7.3 has a very broad list of what it runs on, but (considering I own the hardware in question), does it run on the smallest of the small? VAX-11/725? MicroVAX 2000? In the case of the 11/725 (and the 11/730), minimum memory requirements come to mind. They are limited to 5MB (the MicroVAX 2000 can take far more memory than that and is not a problem there) [snip] Plain VMS 7.3, with DECnet, will run on a 11/725 and uVAX 2000. Just set the MAXPROCESSCNT to 16 or 12 and AUTOGEN. DECwindows -- no way. TCP/IP -- ditto. Maybe you could squeeze in a Fortran compiler. VMStailor will do wonders if you're tight on disk space and do not need all the optional components. /Wilm ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
On Tue, Feb 16, 2016 at 1:57 AM, Wilm Boerhout wrote: > More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. > This level of backwards compatibility is unique. I'm sure 7.3 has a very broad list of what it runs on, but (considering I own the hardware in question), does it run on the smallest of the small? VAX-11/725? MicroVAX 2000? In the case of the 11/725 (and the 11/730), minimum memory requirements come to mind. They are limited to 5MB (the MicroVAX 2000 can take far more memory than that and is not a problem there) The 11/725, by default, comes with the RC25 as its disk, but you can stick a different disk controller on the Unibus (a SCSI controller does nicely if you can find an affordable one, but an SMD controller is easier to locate), and I do know someone who did some sheetmetal cutting and added an external BA11 to their 11/725 where they could put any number of Unibus disk interfaces. In the case of the MicroVAX 2000, it's a busless design and comes with the equivalent of an RQDX3, so is limited to one internal RD54 and one external RD54, though you could give it a go to MOP boot it via Ethernet. The MicroVAX I also has its place on the small end, with Qbus memory and 4MB max, but at least you can toss a Qbus SCSI controller in one and not suffer with the limitations of its RQDX1. So if 7.3 fits on a ~150MB disk and in 4MB or 5MB of RAM, it'll fit on any of these except perhaps an unexpanded 11/725 (but to be fair, not much fit on an RC25, even when it _was_ on the supported list). I'm not decrying 7.3 at all, but having tried to shoehorn 6.2 on a standard MicroVAX II (9MB RAM, 154MB RD54), I do wonder about the small, hardware-constrained machines. For my own collection, I tend to run whatever was common in the day for that specific hardware, anywhere from MicroVMS 4.whatever through VMS 4.7 through VMS 5.5 or so. Again, nothing wrong with 6.x or 7.x if you have memory and disk to handle it, but not having some of the more expandable models, I didn't do much with the more recent versions and the VAX (but plenty with more recent versions and Alpha. Talk about needing more RAM!) -ethan ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
Zane Healy schreef op 15-2-2016 om 18:20: [snip] There are plenty of good VAX and VMS manuals out there, including the documentation set. Check eBay and abebooks.com. The last version of VMS that will run on a VAX is v7.3. Zane More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780. This level of backwards compatibility is unique. The other way around, each "newer" VAX in general needs a minimum version of VMS to run. Sometimes special "hardware releases" were issued (such as V5.5-H2) to support a new VAX model or variant. /Wilm ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
below... On Mon, Feb 15, 2016 at 12:14 PM, Will Senn wrote: > What is a good source to learn a bit about VAX/VMS and the relationship of > the VAX and PDP-11 architectures and programming differences? Hmm probably this list😈 > I looked at the Wikipedia article. I'm not sure it is entirely accurate > and it is sketchy on particulars. > Which one - the VAX/VMS article? > > Also, can the Vax run v6 or v7? > 32V is the original V7 to the 780. Nothing there much that you will learn that you can not learn from V7 on the 11/70. It does have a newer compiler. If you want to see UNIX on an 780, start with BSD 4.1 > > Thanks, > > Will > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS
> > On Feb 15, 2016, at 9:14 AM, Will Senn wrote: > > What is a good source to learn a bit about VAX/VMS and the relationship of > the VAX and PDP-11 architectures and programming differences? I looked at the > Wikipedia article. I'm not sure it is entirely accurate and it is sketchy on > particulars. > > Also, can the Vax run v6 or v7? > > Thanks, > > Will There are plenty of good VAX and VMS manuals out there, including the documentation set. Check eBay and abebooks.com. The last version of VMS that will run on a VAX is v7.3. Zane ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX/VMS
What is a good source to learn a bit about VAX/VMS and the relationship of the VAX and PDP-11 architectures and programming differences? I looked at the Wikipedia article. I'm not sure it is entirely accurate and it is sketchy on particulars. Also, can the Vax run v6 or v7? Thanks, Will Sent from my iPhone Sent from my iPhone ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX VMS cluster under SIMH V4.0
On Wednesday, November 18, 2015 at 5:35 AM, Mark Pizzolato wrote: > Once again, PLEASE provide the output of the following commands when > running SIMH V4.0!! > > sim> SHOW VERSION > sim> SHOW ETHERNET If you're running your simulators with root privileges, then please be sure to execute the above commands as root as well. > Thanks. > > - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX VMS cluster under SIMH V4.0
Hi Dave, Once again, PLEASE provide the output of the following commands when running SIMH V4.0!! sim> SHOW VERSION sim> SHOW ETHERNET Thanks. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX VMS cluster under SIMH V4.0
This config works under 3.9-0 The 3900 config is: set console brk=4 load -r /simh/vax/ka655x.bin set cpu 256m set dz enable set dz lines=4 attach dz 5104 att nvr /simh/vax/nvr.img set rq0 rauser=4096 attach rq0 /simh/vax/rq0.dsk set rq1 disable set rq2 disable set rq3 disable set rl disable set ry disable set ts disable set tq disable set xq enable set xq mac=08-00-11-C3-56-39 set xq type=delqa att xq0 eth0 set cpu conhalt set cpu idle d wru 6 d bdr 0 b cpu MicroVAX 3900 simulator V4.0-0 Betagit commit id: 4a1cf358 Listening on port 5104 NVR: buffering file in memory ./vax3900.cfg-14> set ry disable Non-existent device Eth: Must specify actual tap device name (i.e. tap:tap0) KA655X-B V5.3, VMB 2.7 Performing normal system tests. 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25.. 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. 08..07..06..05..04..03.. Tests completed. Loading system software. (BOOT/R5:1000 DUA0 The 780 config is: VAX 11/780 simulator V4.0-0 Betagit commit id: 4a1cf358 Listening on port 5100 Eth: Must specify actual tap device name (i.e. tap:tap0) Loading boot code from internal vmb.exe set cpu 128M set dz lines=8 attach dz 5100 set rq0 rauser=4096 attach rq0 /simh/vax/rq0.dsk set rq1 disable set rq2 disable set rq3 disable set hk disable set rl disable set rp disable set ry disable set ts disable set tq disable set tu disable set xu enable set xu mac=08-00-11-C3-56-B4 set xu type=delua att xu0 eth0 set cpu conhalt set cpu idle d wru 6 b rq0 %SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk %SYSBOOT-I-SYSBOOT SYSDUMP.DMP on System Disk successfully mapped %SYSBOOT-I-SYSBOOT Mapping PAGEFILE.SYS on the System Disk %SYSBOOT-I-SYSBOOT SAVEDUMP parameter not set to protect the PAGEFILE.SYS OpenVMS (TM) VAX Version V7.3 Major version id = 1 Minor version id = 0 The systems crash when trying to start LAST. Changing the eth device to tap:tap0 allows a system to boot but the second system gives the message: Eth: open error - Device or resource busy on boot. However the booted system cannot contact the Alpha system on the same Linux system and can only be connected to from a remote system ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS under v4.0
Hi Dave, On Tuesday, November 17, 2015 at 2:22 PM, Dave Osborne wrote: > Under V3.9-0 I have a VMS cluster running under SUSE 13.2. I have two > Vaxen running VMS 7.3 and an Alpha emulator running VMS 8.3 under > FreeAXP. The Vaxen boot off a shared image disk with no problem and the > Alpha boots from it's own disk. They all access the Ethernet device eth0 with > no problem and I can access each system from any external system. Great! Booting from a shared image disk has several potential issues. #1) under v3.9 all I/O accessing the file which is the disk image is using stdio (instead of system calls read and write). This means that there is local (in process) buffering which is not coherent between the different processes which may be accessing the same disk image file concurrently and thus updates may be inconsistent. If the disk has been used extensively (for write activities) and there has been no corruption, then you've been lucky. Under V4.0, the shared disk image can be accessed in "RAW" mode which uses system calls read and write directly and provides coherent access to the shared file. #2) VMS MUST be configured to know that the same disk image is being referenced by multiple systems concurrently (via under the covers hardware sharing instead of one system accessing the disk across the cluster via the MSCP disk server which would only have one hardware path to the disk). How have you convinced both of these VMS systems that this is the case? - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX VMS under V4.0
Hi Dave, On Tuesday, November 17, 2015 at 3:27 PM, Dave Osborne wrote: > Hi Mark, > > Under V3.9 this works. Thanks for the V3.9 configuration files. Once again, Can you provide the exact configuration files you've given BOTH simulators AND exactly what was output by the simulator when you are observing an issue. Also, please provide the output of: sim> SHOW VERSION sim> SHOW ETHERNET Cutting and pasting the precise output for the errors and the above information, is what I'm looking for Thanks. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX VMS under V4.0
Hi Mark, Under V3.9 this works. The first VAX is configured as a 780. The config file is: set cpu 128M set dz lines=8 attach dz 5100 set rq0 rauser=4096 attach rq0 /simh/vax/rq0.dsk set rq1 disable set rq2 disable set rq3 disable set hk disable set rl disable set rp disable set ry disable set ts disable set tq disable set tu disable set xu enable set xu mac=08-00-11-C3-56-B4 set xu type=delua att xu0 eth0 set cpu conhalt set cpu idle d wru 6 b rq0 The second VAX is configured as a 3900 and the config file is: set console brk=4 load -r /simh/vax/ka655x.bin set cpu 256m set dz enable set dz lines=4 attach dz 5104 att nvr /simh/vax/nvr.img set rq0 rauser=4096 attach rq0 /simh/vax/rq0.dsk set rq1 disable set rq2 disable set rq3 disable set rl disable set ts disable set tq disable set xq mac=08-00-11-C3-56-39 set xq type=delqa att xq0 eth0 set cpu conhalt set cpu idle d wru 6 d bdr 0 b cpu I upgraded the pcap development to the latest version and the VAX simulators now simply report that eth has been connected to device tap0 although none is configured. They do not communicate over the eth device. I configured tun/tap and changing eth0 to tun:tap0 the 780 simulator boots and joins the cluster using the Alpha on eth0. If I drop the 780 and boot the 3900 it boots using tun:tap0 boots but does not see the cluster. If I try to bring both up the first node is OK. The second node reports that eth is busy. Adding a tap1 for the second node does not change this. Regards Dave -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of simh-requ...@trailing-edge.com Sent: 15 November 2015 17:00 To: simh@trailing-edge.com Subject: Simh Digest, Vol 142, Issue 11 Send Simh mailing list submissions to simh@trailing-edge.com To subscribe or unsubscribe via the World Wide Web, visit http://mailman.trailing-edge.com/mailman/listinfo/simh or, via email, send a message with subject or body 'help' to simh-requ...@trailing-edge.com You can reach the person managing the list at simh-ow...@trailing-edge.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Simh digest..." Today's Topics: 1. Re: DG Nova booting from another file or "device"? (Microtech Dart) -- Message: 1 Date: Sat, 14 Nov 2015 16:35:33 -0600 From: Microtech Dart To: Dell Setzer Cc: SIMH mailing list Subject: Re: [Simh] DG Nova booting from another file or "device"? Message-ID: Content-Type: text/plain; charset="utf-8" Thank you, Dell, and Sandy Strain, both of your responses were EXTREMELY helpful to me, and these all worked! Do either of you have any additional thoughts about how I could make what I believe to be a bootable file (extracted from a Microtech/Point4 QIC tape) into a bootable device for the Nova? I'll start with the Minicom Disk To Tape Utility: http://microtechm1.blogspot.com/2015/09/minicom-disk-to-tape-copy-utility.html I've attached a .zip of the binary file that I extracted from this tape for reference. It's very small, so I zipped it up only so that the emailing process didn't interfere with or reject it. Thanks, all! -AJ On Sat, Nov 14, 2015 at 7:23 AM, Dell Setzer wrote: > It's actually pretty easy. After booting RDOS, press ^E to return to > the > sim> prompt. Then, attach a host file to the MTA0 unit. If you give a > sim> host > filename that doesn't yet exist, SIMH will create an empty tape file > and attach it to MTA0: > > sim> attach mta0 testtape.tap > MTA: creating new file > sim> > > Then, give the simh G command to return to RDOS and init/f the MT0 > tape unit. Note that at the sim> prompt, the unit is called "MTA0" (or > MTA1, MTA2, etc), while in RDOS the unit is called "MT0" (or MT1, MT2, etc): > > sim> g > R init/f mt0 CONFIRM? > R > > Now you can dump or copy files to the MT0 device: > dump/v mt0:0 -.sr > LITMACS.SR > OSID.SR > NSID.SR > PARS.SR > ALMSPD.SR > > R > dump/v mt0:1 -.sv > BURST.SV > INITIALIZE.SV > SEDIT.SV > MACXR.SV > EDIT.SV > > R > release mt0 > R > > After releaseing the tape, press ^E again to get to the sim> prompt > and detach the tape file: > ^E > sim> detach mta0 > sim> > Now you can inspect the testtape.tap tape image. > > Attaching an existing tape file is similar, except that at the RDOS > prompt you'd do INIT rather than INIT/F: > > sim> attach mta0 testtape.tap > sim> g > R > init mt0 > R > load/n mt0:0 > LITMACS.SR10/20/83 > OSID.SR 01/10/84 > NSID.SR 10/20/83 > PARS.SR 01/31/85 > > R > load/n mt0:1 > BURST.SV 05/09/85 > INITIALIZE.SV 05/02/85 > SEDIT.SV 05/02/85 > > R > release mt0 > R > > Hope this helps, > ...dell > > On Sat, 14 Nov 2015, Microtech Dart wrote: > > Hi, I am completely new here, although I recognize the n
Re: [Simh] VAX/VMS under v4.0
On Tuesday, November 17, 2015 at 2:22 PM. Dave Osborne wrote: > Under V3.9-0 I have a VMS cluster running under SUSE 13.2. I have two > Vaxen running VMS 7.3 and an Alpha emulator running VMS 8.3 under > FreeAXP. The Vaxen boot off a shared image disk with no problem and the > Alpha boots from it's own disk. They all access the Ethernet device eth0 with > no problem and I can access each system from any external system. Great! > > I decided to build V4.0. First problem is that the simulator complains about > eth0...needing a tun/tap device. I configured my system for tun/tap devices. > OK the first system boots OK. The second VAX boots and complains that the > eth device is busy. Before I dig any further can anyone give me some > pointers. And why can't I connect to the eth0 device! > > And then onto the Alpha... Hi Dave, The above description is somewhat vague. Can you provide the exact configuration files you've given BOTH simulators AND exactly what was output by the simulator when you are observing an issue. Also, please provide the output of: sim> SHOW VERSION sim> SHOW ETHERNET Also, please provide the configuration files you used when things were working under simh v3.9. Thanks. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX/VMS under v4.0
Hello, Under V3.9-0 I have a VMS cluster running under SUSE 13.2. I have two Vaxen running VMS 7.3 and an Alpha emulator running VMS 8.3 under FreeAXP. The Vaxen boot off a shared image disk with no problem and the Alpha boots from it's own disk. They all access the Ethernet device eth0 with no problem and I can access each system from any external system. Great! I decided to build V4.0. First problem is that the simulator complains about eth0...needing a tun/tap device. I configured my system for tun/tap devices. OK the first system boots OK. The second VAX boots and complains that the eth device is busy. Before I dig any further can anyone give me some pointers. And why can't I connect to the eth0 device! And then onto the Alpha... Regards Dave ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Hi Bill, My responses inline in GREEN. From: Bill Deegan [mailto:b...@baddogconsulting.com] Sent: Tuesday, October 20, 2015 2:54 PM To: Mark Pizzolato - Info Comm Cc: simh@trailing-edge.com Subject: Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address Mark, See responses inline. On Tue, Oct 20, 2015 at 2:39 PM, Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> wrote: Hi Bill, I’m still looking for details on your network vision/requirements: Do you expect communicate between the host system and the simulated VMS environment? If so, how were you thinking you’d achieve this? No need. You do have a unique IP address for use by the VMS system, right? Historical questions relating to some possible solutions to achieve the, as yet not completely specified, network goals: Have you previously had LAT enabled on the original VMS system? Yes. But no longer needed. LAT startup has been commented out. Was this VMS system ever part of a VMS Cluster environment? Yes. But no longer needed. You should also do the following: $ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET VAXCLUSTER 0 SYSGEN> SET SCSSYSTEMID 0 SYSGEN> WRITE CURRENT Change the same values in SYS$SYSTEM:MODPARAMS.DAT so that you won’t get surprised by some future AUTOGEN you might do. Reboot your system. -Bill - Mark From: Bill Deegan [mailto:b...@baddogconsulting.com<mailto:b...@baddogconsulting.com>] Sent: Tuesday, October 20, 2015 2:21 PM To: Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> Cc: simh@trailing-edge.com<mailto:simh@trailing-edge.com> Subject: Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address Mark, The system is running multinet, so accessing the system vi TCP/IP and telnet will be sufficient for this application. Not cluster not decnet needed. -Bill On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> wrote: Hi Bill, You want VMS to not try and change the MAC address. On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > We're running on EC2 so DECnet's a no go. So, exactly how do you plan/want to access the simulated VAX? What do you envision the network to look like? > We've disabled the DECnet startup on the system, but when I turn on tracing I > see: > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: > AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > Is there a way to enable the debugging before booting up the VAX? The same debugging commands that enabled the above XQ debug output can certainly be put in the vax configuration file. I'm not sure how that will help anything. > Barring that is there a way to prevent simh catching the "setup packet" and > changing the SRC MAC address? Something in VMS is changing the MAC address on the simulated interface by issuing the appropriate I/O operations to do this. It may be DECnet or it may also be other networking things on the system. Before we dig into the details of that, answering the above questions about how you envision the network to look will be more helpful. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
On Tuesday, October 20, 2015 at 2:56 PM, Johnny Billquist wrote: > Bill - just a quick check. Does it really matter that the MAC address > gets set? Do you have some other device that also sets the same MAC > address? Otherwise the MAC address don't really matter. It's just 48 > bits that needs to be unique. I agree, that in general it should not matter one way or another. However I suspect that the EC2 environment he's running under has specific knowledge of the MAC address they've assigned him and so it probably does matter or he'd already have gotten further along. > Johnny > > On 2015-10-20 23:53, Bill Deegan wrote: > > Mark, > > > > See responses inline. > > > > On Tue, Oct 20, 2015 at 2:39 PM, Mark Pizzolato - Info Comm > > mailto:m...@infocomm.com>> wrote: > > > > Hi Bill, > > > > __ __ > > > > I’m still looking for details on your network vision/requirements: > > > > __ __ > > > > Do you expect communicate between the host system and the simulated > > VMS environment? If so, how were you thinking you’d achieve this? > > > > > > No need. > > > > > > > > __ __ > > > > Historical questions relating to some possible solutions to achieve > > the, as yet not completely specified, network goals: > > > > __ __ > > > > Have you previously had LAT enabled on the original VMS system? > > > > > > Yes. But no longer needed. LAT startup has been commented out. > > > > > > > > __ __ > > > > Was this VMS system ever part of a VMS Cluster environment? > > > > > > Yes. But no longer needed. > > > > > > -Bill > > > > > > > > __ __ > > > > - Mark > > > > __ __ > > > > *From:*Bill Deegan [mailto:b...@baddogconsulting.com > > <mailto:b...@baddogconsulting.com>] > > *Sent:* Tuesday, October 20, 2015 2:21 PM > > *To:* Mark Pizzolato - Info Comm > <mailto:m...@infocomm.com>> > > *Cc:* simh@trailing-edge.com <mailto:simh@trailing-edge.com> > > *Subject:* Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting > > MAC address > > > > __ __ > > > > Mark, > > > > The system is running multinet, so accessing the system vi TCP/IP > > and telnet will be sufficient for this application. > > > > Not cluster not decnet needed. > > > > -Bill > > > > __ __ > > > > On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm > > mailto:m...@infocomm.com>> wrote: > > > > Hi Bill, > > > > You want VMS to not try and change the MAC address. > > > > On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > > > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > > > We're running on EC2 so DECnet's a no go. > > > > So, exactly how do you plan/want to access the simulated VAX? > > > > What do you envision the network to look like? > > > > > We've disabled the DECnet startup on the system, but when I > > turn on tracing I see: > > > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 > > src: AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > > > > > Is there a way to enable the debugging before booting up the VAX? > > > > The same debugging commands that enabled the above XQ debug > > output can certainly be put in the vax configuration file. > > > > I'm not sure how that will help anything. > > > > > Barring that is there a way to prevent simh catching the > > "setup packet" and changing the SRC MAC address? > > > > Something in VMS is changing the MAC address on the simulated > > interface by issuing the appropriate I/O operations to do this. > > It may be DECnet or it may also be other networking things on > > the system. > > > > Before we dig into the details of that, answering the above > > questions about how you envision the network to look will be > > more helpful. > > > > - Mark > > > > > > > > __ __ > > > > > > > > > > ___ > > Simh mailing list > > Simh@trailing-edge.com > > http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > -- > 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 > ___ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Bill - just a quick check. Does it really matter that the MAC address gets set? Do you have some other device that also sets the same MAC address? Otherwise the MAC address don't really matter. It's just 48 bits that needs to be unique. Johnny On 2015-10-20 23:53, Bill Deegan wrote: Mark, See responses inline. On Tue, Oct 20, 2015 at 2:39 PM, Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> wrote: Hi Bill, __ __ I’m still looking for details on your network vision/requirements: __ __ Do you expect communicate between the host system and the simulated VMS environment? If so, how were you thinking you’d achieve this? No need. __ __ Historical questions relating to some possible solutions to achieve the, as yet not completely specified, network goals: __ __ Have you previously had LAT enabled on the original VMS system? Yes. But no longer needed. LAT startup has been commented out. __ __ Was this VMS system ever part of a VMS Cluster environment? Yes. But no longer needed. -Bill __ __ - Mark __ __ *From:*Bill Deegan [mailto:b...@baddogconsulting.com <mailto:b...@baddogconsulting.com>] *Sent:* Tuesday, October 20, 2015 2:21 PM *To:* Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> *Cc:* simh@trailing-edge.com <mailto:simh@trailing-edge.com> *Subject:* Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address __ __ Mark, The system is running multinet, so accessing the system vi TCP/IP and telnet will be sufficient for this application. Not cluster not decnet needed. -Bill __ __ On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> wrote: Hi Bill, You want VMS to not try and change the MAC address. On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > We're running on EC2 so DECnet's a no go. So, exactly how do you plan/want to access the simulated VAX? What do you envision the network to look like? > We've disabled the DECnet startup on the system, but when I turn on tracing I see: > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > Is there a way to enable the debugging before booting up the VAX? The same debugging commands that enabled the above XQ debug output can certainly be put in the vax configuration file. I'm not sure how that will help anything. > Barring that is there a way to prevent simh catching the "setup packet" and changing the SRC MAC address? Something in VMS is changing the MAC address on the simulated interface by issuing the appropriate I/O operations to do this. It may be DECnet or it may also be other networking things on the system. Before we dig into the details of that, answering the above questions about how you envision the network to look will be more helpful. - Mark __ __ ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- 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 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Mark, See responses inline. On Tue, Oct 20, 2015 at 2:39 PM, Mark Pizzolato - Info Comm < m...@infocomm.com> wrote: > Hi Bill, > > > > I’m still looking for details on your network vision/requirements: > > > > Do you expect communicate between the host system and the simulated VMS > environment? If so, how were you thinking you’d achieve this? > No need. > > > Historical questions relating to some possible solutions to achieve the, > as yet not completely specified, network goals: > > > > Have you previously had LAT enabled on the original VMS system? > Yes. But no longer needed. LAT startup has been commented out. > > > Was this VMS system ever part of a VMS Cluster environment? > Yes. But no longer needed. -Bill > > > - Mark > > > > *From:* Bill Deegan [mailto:b...@baddogconsulting.com] > *Sent:* Tuesday, October 20, 2015 2:21 PM > *To:* Mark Pizzolato - Info Comm > *Cc:* simh@trailing-edge.com > *Subject:* Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC > address > > > > Mark, > > The system is running multinet, so accessing the system vi TCP/IP and > telnet will be sufficient for this application. > > Not cluster not decnet needed. > > -Bill > > > > On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm < > m...@infocomm.com> wrote: > > Hi Bill, > > You want VMS to not try and change the MAC address. > > On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > > We're running on EC2 so DECnet's a no go. > > So, exactly how do you plan/want to access the simulated VAX? > > What do you envision the network to look like? > > > We've disabled the DECnet startup on the system, but when I turn on > tracing I see: > > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: > AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > > > Is there a way to enable the debugging before booting up the VAX? > > The same debugging commands that enabled the above XQ debug output can > certainly be put in the vax configuration file. > > I'm not sure how that will help anything. > > > Barring that is there a way to prevent simh catching the "setup packet" > and changing the SRC MAC address? > > Something in VMS is changing the MAC address on the simulated interface by > issuing the appropriate I/O operations to do this. It may be DECnet or it > may also be other networking things on the system. > > Before we dig into the details of that, answering the above questions > about how you envision the network to look will be more helpful. > > - Mark > > > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Hi Bill, I’m still looking for details on your network vision/requirements: Do you expect communicate between the host system and the simulated VMS environment? If so, how were you thinking you’d achieve this? Historical questions relating to some possible solutions to achieve the, as yet not completely specified, network goals: Have you previously had LAT enabled on the original VMS system? Was this VMS system ever part of a VMS Cluster environment? - Mark From: Bill Deegan [mailto:b...@baddogconsulting.com] Sent: Tuesday, October 20, 2015 2:21 PM To: Mark Pizzolato - Info Comm Cc: simh@trailing-edge.com Subject: Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address Mark, The system is running multinet, so accessing the system vi TCP/IP and telnet will be sufficient for this application. Not cluster not decnet needed. -Bill On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm mailto:m...@infocomm.com>> wrote: Hi Bill, You want VMS to not try and change the MAC address. On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > We're running on EC2 so DECnet's a no go. So, exactly how do you plan/want to access the simulated VAX? What do you envision the network to look like? > We've disabled the DECnet startup on the system, but when I turn on tracing I > see: > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: > AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > Is there a way to enable the debugging before booting up the VAX? The same debugging commands that enabled the above XQ debug output can certainly be put in the vax configuration file. I'm not sure how that will help anything. > Barring that is there a way to prevent simh catching the "setup packet" and > changing the SRC MAC address? Something in VMS is changing the MAC address on the simulated interface by issuing the appropriate I/O operations to do this. It may be DECnet or it may also be other networking things on the system. Before we dig into the details of that, answering the above questions about how you envision the network to look will be more helpful. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Mark, The system is running multinet, so accessing the system vi TCP/IP and telnet will be sufficient for this application. Not cluster not decnet needed. -Bill On Tue, Oct 20, 2015 at 1:55 PM, Mark Pizzolato - Info Comm < m...@infocomm.com> wrote: > Hi Bill, > > You want VMS to not try and change the MAC address. > > On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > > We're running on EC2 so DECnet's a no go. > > So, exactly how do you plan/want to access the simulated VAX? > > What do you envision the network to look like? > > > We've disabled the DECnet startup on the system, but when I turn on > tracing I see: > > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: > AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > > > Is there a way to enable the debugging before booting up the VAX? > > The same debugging commands that enabled the above XQ debug output can > certainly be put in the vax configuration file. > > I'm not sure how that will help anything. > > > Barring that is there a way to prevent simh catching the "setup packet" > and changing the SRC MAC address? > > Something in VMS is changing the MAC address on the simulated interface by > issuing the appropriate I/O operations to do this. It may be DECnet or it > may also be other networking things on the system. > > Before we dig into the details of that, answering the above questions > about how you envision the network to look will be more helpful. > > - Mark > > > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Hi Bill, You want VMS to not try and change the MAC address. On Tuesday, October 20, 2015 at 1:31 PM, Bill Deegan wrote: > I'm migrating a VMS 6.2 system from real hardware to simh VAX. > We're running on EC2 so DECnet's a no go. So, exactly how do you plan/want to access the simulated VAX? What do you envision the network to look like? > We've disabled the DECnet startup on the system, but when I turn on tracing I > see: > DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: > AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 > > Is there a way to enable the debugging before booting up the VAX? The same debugging commands that enabled the above XQ debug output can certainly be put in the vax configuration file. I'm not sure how that will help anything. > Barring that is there a way to prevent simh catching the "setup packet" and > changing the SRC MAC address? Something in VMS is changing the MAC address on the simulated interface by issuing the appropriate I/O operations to do this. It may be DECnet or it may also be other networking things on the system. Before we dig into the details of that, answering the above questions about how you envision the network to look will be more helpful. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX/VMS 6.2 DECnet turned off, still resetting MAC address
Greetings, I'm migrating a VMS 6.2 system from real hardware to simh VAX. We're running on EC2 so DECnet's a no go. We've disabled the DECnet startup on the system, but when I turn on tracing I see: DBG(42740138541)+> XQ ETH: writing dst: 02:41:0C:98:92:09 src: AA:00:04:00:20:10 proto: 0x0800 len: 98 crc: B5981F43 Is there a way to enable the debugging before booting up the VAX? Barring that is there a way to prevent simh catching the "setup packet" and changing the SRC MAC address? -Bill ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] SimH VAX/VMS autoshutdown
A few years back, I modified SimH to support auto shutdown of VMS when the hostg system (Windows) was shutting down (and under a few other conditions). This required some registry changes to ensure that windows waited long enough for VMS to shutdown. The shutdown mechanism was rather crude - the Card Reader had a job deck in it that shutdown VMS. A change was made to the console program to trap the appropiate windows events. When one of these events was triggered, the CR was reset and the code snippet would go into a tight loop waiting for a flag that indicated control had been returned to the console, at which time the task was terminated. I think that it would also be nice to have something similar coded that would work for *IX. Perhaps there is a better way to managed the process other than using the card reader.. Anyway, if anyone is willing to do what is necessary to migrate this code into the general distribution, I would be more than willing to send them what I have - in the way of code & documentation.. Villy ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
