Y2K, 2038 Unix timeout, IBM5100
- Thread starter MEM
- Start date
Hercules
Temporal Navigator
I have discussed about this topic in another thread.
http://www.timetravelinstitute.com/ttiforum/showflat.php?Cat=&Board=time_travel&Number=34323&page=1&view=collapsed&sb=5&o=&fpart=all
There are a lot of “other†issues involved in the emulator issue. My probe in this story is that, YES it is impossible to make an emulator WITHOUT the IBM 5100 in John Titor’s worldline. That is the reason he traveled back to get an IBM 5100. The unique feature of the IBM 5100 is it had the s/360 emulator hard coded into its ROM. That was what is needed in Titor’s worldline. Titor “used†our Worldline to make an emulator for his worldline.
The most important aspect of Titor story is that how it relates to real-life events.
Roger Bowler made an s/360 emulator in our worldline. But it was impossible to make an s/360 emulator before 1998. “HOW†did he make the emulator is VERY, VERY interesting. He gave the emulator for FREE. Why would he give it for free if he had put a LOT(considering he built it without the IBM 5100) of effort into it? Why would someone take a job that has no gain from it? He said it was his long time “dream†to make an emulator, but he started working on it only after 1998.
Making the emulator was quite simple with the IBM 5100’s s/360 emulator in the ROM. This was made possible in our Worldline by Titor in 1998 with the “tweaked†IBM 5100 from 1975.
Now I am clear with this part and I like to discuss it with you if you find any discrepancies.
Hercules
Temporal Navigator
Here he says Y2K is a disaster in his Worldline. While the other statements pertain to the civil war. The fact that Y2K leads to a civil war in 2005 is ridiculous. Y2K would only have made the companies spend too much $$ for the conversions through outsourcing. Titor could have prevented Y2K with the IBM 5100 in 1998(not part of his mission, but he has to do it to get the emulator).
From the developer of the emulator:
The other statements in the quote relate to the “natural disaster†in 2005 which he said he would not reveal.
MadIce
Chrono Cadet
What people seem to forget is that the Y2K problem and the Year 2038 problem are really different.
The Y2K problem was mostly about software that didn't give/have room for the century digits OR used BCD representation for dates and time stamps in which to save space the century digits were ommited (sometimes in hardware, sometimes in software) OR did have a rollover problem in 2000 OR did have a problem with the leap-year calculation of 2000, etc. It depended on the applications, the harware platform, the operating system and the programming languages used what the problem exactly was.
The year 2038 problem is about a 32-bit 2s-complement integer counter that flips to a negative number somewhere in 2038. You need the source of both the applications and the operating systems to correct it. The problem is present in Unix-like operating systems AND operating systems and software written in the languages C and/or C++ AND software written in other (scripting) languages created with C/C++.
As you may have noticed 64-bit computers start to become mainstream. These computers will use a 64-bit operating system in which the 32-bit counter has been replaced by a 64-bit one. New applications written for that OS or ported to it will not have the problem. In 2038 it is likely that most of the old 32-bit software and hardware have died out. Only a few machines will be using old hardware or legacy software. It is therefore very unlikely that the Year 2038 problem will present a real threat to society.
BTW: Chances are slim that in 2038 we'll use silicon based computers anyway. But that's a different discussion.
The Y2K problem was mostly about software that didn't give/have room for the century digits OR used BCD representation for dates and time stamps in which to save space the century digits were ommited (sometimes in hardware, sometimes in software) OR did have a rollover problem in 2000 OR did have a problem with the leap-year calculation of 2000, etc. It depended on the applications, the harware platform, the operating system and the programming languages used what the problem exactly was.
The year 2038 problem is about a 32-bit 2s-complement integer counter that flips to a negative number somewhere in 2038. You need the source of both the applications and the operating systems to correct it. The problem is present in Unix-like operating systems AND operating systems and software written in the languages C and/or C++ AND software written in other (scripting) languages created with C/C++.
As you may have noticed 64-bit computers start to become mainstream. These computers will use a 64-bit operating system in which the 32-bit counter has been replaced by a 64-bit one. New applications written for that OS or ported to it will not have the problem. In 2038 it is likely that most of the old 32-bit software and hardware have died out. Only a few machines will be using old hardware or legacy software. It is therefore very unlikely that the Year 2038 problem will present a real threat to society.
BTW: Chances are slim that in 2038 we'll use silicon based computers anyway. But that's a different discussion.
Hercules
Temporal Navigator
Yeah it is a hardware emulator released by IBM in 1983. You did NOT get my point. I am talking about a software emulator like the one I pointed out(Hercules developed by Roger Bowler).
I CHALLENGE you that you cannot find one that is developed before April 1998. This is the key point in the Titor story.
A brief history pertaining to this topic:
The first publicly available APL system was the costfree “Type 111†program (available without formal support) released in 1968. It was followed in 1969 by the two program products (PPS) shown in the chart. These were among the very first programs offered when IBM unbundled programs and hardware. An important decision taken then, which would influence the progress of APL in ways that even now are not completely understood, was to hold back the source code and release only object code to customers. This was done deliberately, to discourage proliferation of language variants and to give the original designers a better chance of directing the further evolution of APL along a coherent and consistent path. A positive effect of this policy was to facilitate formal standardization of APL later on, and the ad hoc standardization that resulted from having a single control point simplified the development of other APL products along the way. A possible negative effect was the discouragement of interest in APL as a subject of university research.
APL\1130. In 1965-1966 the IBM Los Gatos Laboratory in California was working on the design of a very small, low-cost (hence LC or “Elsiey’) machine. It was to have a relatively simplein struction set and an internal memory of only 1024 words, supplemented by an external magnetic disk, about eight inches in diameter, which used grooveosn one side for mechanically indexing to the magnetic tracks. Science Research Associates, then a subsidiary of IBM, was interested in the educational potential of such a machine, and commissioned a study to produce an APL system for it. Two of the three people who conducted the study had previously worked on IVSYS.†Drawing on this experience, the group proposed a modified architecture for Elsie, better suited to implementing APL. An emulator for this machine design, and an assembler for programming it, were written for the IBM Model 7090, and design of the APL system proceeded from there. The result was then successfully transferred to a real Elsie prototype, so that in due course an APL system was running in Los Gatos. Unfortunately, business considerations kept Elsie from ever becoming a product, but the work on it was not wasted. By 1967 APL\360 was becoming widely known within IBM, and the Research APL group was approached by an IBM branch office interested in the possibility of having an APL system available for the IBM Model 1130, a midsize “scientific†machine. To quickly produce a prototype and show feasibility, an Elsie emulator was written for the Model 1130 and the APL system was installed on it. It ran successfully. To improve performance, one additional instruction was added to the Elsie emulator, an escape to the native 1130 architecture, which was used as the path to more efficient coding of successive parts of the interpreter. As shown in Figure 1, an upgraded APL\1130 was later produced as an IBM Type I11 program. Not shown in the figure is a more formal APL\1130 product that had a very short life. It was a timesharing upgrade of the Type I11 program, produced by the APL development group in Palo Alto, which was then still part of the Systems Development Division. It was shipped to one or two customers befor being withdrawn from the market. But it, too, was not wasted. Indeed, it figured importantly in the early development of the modern personal computer.
APL 5100. In late1 972 the Palo Alto Scientific Center was asked by IBM’s General Systems Division headquarters in Atlanta, Georgia, to suggest an APL product suitable for production by their division. In response, the Scientific Center proposed an entrylevel machine that could fit on a desk. This suggestion was accepted, and they proceeded to assemble a team composed of people with hardware knowledge from Los Gatos and people with software knowledge from the Scientific Center to work on thed esign. The team selected a processor engine known internally as “Palm†for the machine’s central processing unit, in preference to another, called uC.5, that was also available at the time. Once again, the quickest way to show feasibilityan d produce a prototype was to emulate an existing machine that already had APL programmed for it. In this case, the Model 1130 was chosen. Thus, APL\1130, a system that had its origins in Elsie, the earlier Los Gatos machine, and that had been ported by emulation to the Model 1130, where it was eventually converted to native 1130 architecture code, was now ported to a new machine in which Los Gatos was also involved inth e hardware design. The functioning prototype, know as SCAMP (Special Computer APL Machine Portable), was produced in the short time of six months, and was successful in persuading the General Systems Division to proceed with a production machine.% At present the SCAMP prototype, an APL machine that was the unique forerunner of the first production personal computer, resides in the collection of the Smithsonian Institution in Washington, DCz9 The production machine was designed at IBM’s General Systems Division laboratory at Rochester, Minnesota, and was made available as a product, the IBM 5100 machine, in 1974-less than a year and a half from the start. This remarkably short development cycle for such a complex new product can be attributed in large part to the fact that emulation was used again, even in the final product. This time, however, although the same Palm internal engine was used, System/360 architecture was emulated rather than 1130 architecture, so that the up-to-date APLSV product system could be used as the APL facility with virtually no modification. There were some changes, however, that anticipated later developments in personal computers. For example, the primary input/output device was a cathode ray tube with an associated keyboard that included an extra shift, named “CMD,†and a number pad; there was a software switch to enter a communication mode to enable the machine to act as a terminal on a host system; and another switch to automatically copy input and output to an attached printer.
http://www.research.ibm.com/journal/sj/304/ibmsj3004C.pdf
http://www.research.ibm.com/journal/sj/304
NOTE: The pdf documents are subject to copyright and I have not altered any of the words present in the original document.
My point here is, the IBM 5100 did have a software emulator hard coded into it when it was manufactured. But it was RESTRICTED, meaning that any customer can avail its use, but he CANNOT access the source code and modify it. Titor was sent for this VERY purpose. He has to contact his grandfather, “tweak†the IBM 5100 to get the source code.
The fact that how this relates to Y2K and Y2K38 is vague. I accept it. But I am pretty sure if I can spend time to research it I can definitely prove the interpretation is correct.
Unfortuneatly, this is being discussed on another forum. But for purposes of talking to a person who worked on old systems (a professor in college), once in a while, a record or maintanence had to be performed on those old computers. What is kept by a business on those computers? Records! Perhaps records of financial, medical, or insurance records, and that was just a couple of years back. So saying that they will not keep records as recorded on those computers may be wishing it away, when the business just decides that it would cost too much to update all those records to a new computer system instead of just sending down a programmer who use to work with those computer or is familiar with those computers, and keep those computers just the way that they are still today, pulling out some old record once in a while, and doing maintanence on those computers when they just want to keep them in shape if they ever want to pull out some old record.
If they already kept those computers that way since 30 years ago or so, what is to say they do not keep them for 60 years or so?
They just might, if they still run, and are not used all the time. Businesses are not going to spend all that money to update all those records, whether you think a business should or not. They simply think probably that they can just use those computers the same way they are, and have been, for the last 40 or so years!
Remember, probably the tape is put on the computer which has been stored something akin to older movies they still keep in movie studios -- in a controlled humidity and temperature environment. In movies studios they still have some of those 1930's old movies still stored. How do you think the Wizard of Oz is shown or was shown around every Christmas? Sure copies were made, but from the original they still have in storage!!
/ttiforum/images/graemlins/yum.gif
If they already kept those computers that way since 30 years ago or so, what is to say they do not keep them for 60 years or so?
They just might, if they still run, and are not used all the time. Businesses are not going to spend all that money to update all those records, whether you think a business should or not. They simply think probably that they can just use those computers the same way they are, and have been, for the last 40 or so years!
Remember, probably the tape is put on the computer which has been stored something akin to older movies they still keep in movie studios -- in a controlled humidity and temperature environment. In movies studios they still have some of those 1930's old movies still stored. How do you think the Wizard of Oz is shown or was shown around every Christmas? Sure copies were made, but from the original they still have in storage!!
/ttiforum/images/graemlins/yum.gif
Hercules
Temporal Navigator
Good point. They can keep a computer like IBM 5100 for 60 years. But that won't do any good cuz they cannot keep an Engineer like Titor's grandfather for that 60 years.
Titor's grandfather worked on it and he knows how to "tweak" it and reverse engineer the utility and access the source code. Without an engineer who worked on it in 1975, even if they have an IBM 5100, they cannot do anything to extract the emulator from the ROM chips.
RainmanTime
Super Moderator
Sorry Herc, that statement is pure, utter, 100% baloney! I've already related a story where my college roommate and I were able to download the ROM from an Atari Space Duel game, and "tweak" it in a VERY big way to create a 3-D vector graphics program. Note that NEITHER of us worked on either the 6502 processor nor the Space Duel game in particular. So there you go... this is HARD-FAST evidence to counter your claim. You DO NOT necessarily need one of the engineers who worked on the machine to dis-assemble its code and reverse engineer it. In fact, the whole meaning of the term "reverse engineer" implies that you do not have the knowledge of detail design that the original product engineers had.
I wish you'd be a little less "certain" in your statements that you do NOT know for certain.
RMT
So if S/360 "legacy" applications are still running they are not running on S/360 hardware. What other hardware? How about a Unix box that emulates a S/360?
So why would the Y2038 Unix problem need a "5100 computer ... capable of reading and changing all of the legacy code written by IBM " to fix it?
One reason: The Y2038 fix on a Unix-based emulator causes a problem with S/360 executables running on them. And the binary code needs to be "read and changed" to fix the problem.
An emulator is not capable of that.
RainmanTime
Super Moderator
And you apparantly think you are good at changing the subject without people realizing. Understand, dear sir, that I (and many others) have, through force of will, debunked the statment YOU made. Ergo, you are wrong in making this statement. Let me remind you of the statement you made:
Would you please admit you are incorrect in this statement? The plain fact is that ANY code burned into ROM chips can (and has been) reverse-engineered. All you need to know is the processor that the code runs on (i.e. know its binary instruction set). Stop trying to make it look like I am debunking something I didn't say, Hercules. I am simply holding YOU to TRUTH.
And this is completely irrelevant to the statement you made. Again: If I have a physical ROM and I know what processor its code runs on, and I know that processor's binary instruction set I do not need to have an engineer who helped design the target system in order to reverse engineer the code.
You always seem to make the mistake of believing that I am trying to debunk Titor. That has already been done in many ways, by many people. In actuality, I am simply pointing out where the statements you make (often with an authoritative tone) are incorrect.
RMT