Re: Microsoft open sources GWBASIC
On 5/31/20 3:13 PM, Eric Korpela via cctalk wrote: > Most languages will give you some way to shoot yourself in the foot. The > question is how much work do you need to do? In FORTRAN the easiest method > was changing the value of a literal in a subroutine call. It is standard > compliant behavior that goes back to at least FORTRAN IV. One of the reasons that the F90 standards people got very strict about vendor "features" (must not be allowed as the default) was that they were often added as a "good idea" without a lot of thought. I recall one from the CDC 6000 FORTRAN IV extended product that got everyone thinking. Instead of counting the number of characters in a hollerith constant as used in a FORMAT, some clever boots decided that "Hdxd", where x is the character string and d is any printable character that forms a delimiter would be a really neat feature. Thus, H*HELLO* has exactly the same meaning as 5HHELLO when used in a FORMAT statement. One day a PSR rolled in with the following question: Given the program segment shown below, what does it do? DIMENSION FORMAT(10) INTEGER HX, X HX = 1 X = 2 100 FORMAT(HX)=(-X) Observe that FORTRAN has no reserved words (that changed in F90) and spaces are ignored unless part of a hollerith constant. Well, it might be an assignment to an element of the array FORMAT--or, it might be a FORMAT statement for an I/O operation (FORTRAN does not disallow unreferenced FORMAT statements). Clearly, if there were an I/O statement (e.g. READ or WRITE) referencing label 100, the meaning was obvious. Otherwise, meh. There was no way to "fix" the problem other than to say "Don't be silly". --Chuck
Re: Microsoft open sources GWBASIC
On 2020-05-30 14:18, Boris Gimbarzevsky via cctech wrote: Chuck, your post just reminded me of how I used FORTRAN to interface with my PDP-11 ASM routines when I was doing data acquisition as fast as possible on a MINC system. Perused my FORTRAN code about 6 months ago and had common blocks and a routine which took "arrays" which were essential chunks of PDP-11 memory that I'd use as data buffers and to access data in my ASM routines directly. Certainly a lot faster than doing function calls to get at this data but would now be looked at as very "dangerous" programming. That's why my (long after retirement) interest is mostly in MCU programming, currently the STM32F7 series. The processors have all sorts of interesting memory management hardware built-in, including storage protection, but few people avail themselves of it. For me, this allows this once-engineer to get back to playing with hardware without putting up with the nonsense of a massive operating system. I find that very gratifying in my dotage. Cheers, Chuck
RE: intellec MDS80 on eBay
Still looking for the matching paper tape reader and punch. For one of these...Ed# On Sunday, May 31, 2020 Jan-Benedict Glaw via cctech wrote: Hi! I just wanted to drop an email that there's a MDS 80 on eBay: https://www.ebay.de/itm/333612000595 (Please note: The seller, Michael, is a friend of mine, and a former coworker.) Thanks, Jan-Benedict --
RE: intellec MDS80 on eBay
I assume this are not the standard Intel floppy drives? On Sunday, May 31, 2020 Jan-Benedict Glaw via cctech wrote: Hi! I just wanted to drop an email that there's a MDS 80 on eBay: https://www.ebay.de/itm/333612000595 (Please note: The seller, Michael, is a friend of mine, and a former coworker.) Thanks, Jan-Benedict --
Re: PC Fortran (Was: Microsoft open sources GWBASIC
On Sun, May 31, 2020 at 5:50 PM Bill Gunshannon via cctalk < cctalk@classiccmp.org> wrote: > On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: > > > > > > On the other hand, Intel also had a FORTRAN-80 product, which was > unrelated > > to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development > > systems under the ISIS-II operating system, and the compiler was written > in > > PL/M. > > > > Which is even funnier when you realize that the PL/M compiler > was written in Fortran. > In at least the more recent versions, Intel FORTRAN-80 on ISIS-II was compiled with the ISIS-II PL/M compiler, which was itself written in PL/M. The ISIS-II PL/M compiler was bootstrapped from the PL/M cross-compiler that was written in FORTRAN, and it's entirely possible that early versions of Intel FORTRAN-80 were developed that way as well.
is nexgen cpu and motherboard scarce or rare item? Ed#
is nexgen cpu and motherboard scarce or rare item? Ed#
Re: PC Fortran (Was: Microsoft open sources GWBASIC
Sent from my iPhone. > On May 31, 2020, at 9:16 PM, Bill Gunshannon > wrote: > > On 5/31/20 8:35 PM, Mich.com wrote: >> Sent from my iPhone. On May 31, 2020, at 7:50 PM, Bill Gunshannon via cctalk wrote: >>> >>> On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: On the other hand, Intel also had a FORTRAN-80 product, which was unrelated to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development systems under the ISIS-II operating system, and the compiler was written in PL/M. >>> >>> Which is even funnier when you realize that the PL/M compiler >>> was written in Fortran. >>> >>> bill >> As I recall, it was the cross compiler for PL/M that was written in FORTRAN. >> But that came first, before any 8080-hosted PL/M compiler. > > You are definitely right on that. I forget what it was intended to run > on, probably some minicomputer like a DEC System-10 or -20. Hmmm... I > wonder if it would compile with Fortran-80 on my TRS-80. That might be > fun to see. I even have corrected sources around here somewhere because > after all those years of people using it I found a few bugs in the two > sets of sources that were floating around the Internet. :-) > > bill > I remember the “technical Computer center” people at Chrysler where I worked talking about making the PL/M compiler run on our CDC Cyber computers (60-bit). It was a bit of work. I seem to remember thinking it was written to run on an IBM mainframe, if that makes sense. But they got it working and we used it until Intel came out with their 8080-based development systems. Then we started using them to compile. Dave
Re: PC Fortran (Was: Microsoft open sources GWBASIC
On 5/31/20 8:35 PM, Mich.com wrote: Sent from my iPhone. On May 31, 2020, at 7:50 PM, Bill Gunshannon via cctalk wrote: On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: On the other hand, Intel also had a FORTRAN-80 product, which was unrelated to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development systems under the ISIS-II operating system, and the compiler was written in PL/M. Which is even funnier when you realize that the PL/M compiler was written in Fortran. bill As I recall, it was the cross compiler for PL/M that was written in FORTRAN. But that came first, before any 8080-hosted PL/M compiler. You are definitely right on that. I forget what it was intended to run on, probably some minicomputer like a DEC System-10 or -20. Hmmm... I wonder if it would compile with Fortran-80 on my TRS-80. That might be fun to see. I even have corrected sources around here somewhere because after all those years of people using it I found a few bugs in the two sets of sources that were floating around the Internet. :-) bill
Re: PC Fortran (Was: Microsoft open sources GWBASIC
Sent from my iPhone. > On May 31, 2020, at 7:50 PM, Bill Gunshannon via cctalk > wrote: > > On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: >> On the other hand, Intel also had a FORTRAN-80 product, which was unrelated >> to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development >> systems under the ISIS-II operating system, and the compiler was written in >> PL/M. > > Which is even funnier when you realize that the PL/M compiler > was written in Fortran. > > bill As I recall, it was the cross compiler for PL/M that was written in FORTRAN. But that came first, before any 8080-hosted PL/M compiler.
Re: Microsoft open sources GWBASIC
He amassed a huge collection, then sold the lot and bought a Tesla. :-) On Mon, 1 Jun 2020, Tony Duell via cctalk wrote: Assuming a 'Tesla' is an electric car, I'd rather be in the reverse position (selling said car and being able to buy some interesting old computers...)] A Tesla is a rather expensive electric car, a product of Elon Musk. STARTING (minimal stripped down) at 40,000 pounds, and some models over 80,000 pounds. Sell one of THOSE, and you can buy a car AND a lot of great computer stuff. Although some early Apples could go for ten times that.
Re: PC Fortran (Was: Microsoft open sources GWBASIC
On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: On the other hand, Intel also had a FORTRAN-80 product, which was unrelated to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development systems under the ISIS-II operating system, and the compiler was written in PL/M. Which is even funnier when you realize that the PL/M compiler was written in Fortran. bill
Anyone know what an AM000076 (Dip 18) is?
Title says all, Backing up all the programmable parts in the Apollo DN100 and the CPU board has a few of these ceramic DIPs with the same Apollo P/N labels as the Am27S29 and similar programmable parts. Thanks
Re: Microsoft open sources GWBASIC
On Sun, May 31, 2020 at 5:53 PM Liam Proven via cctalk wrote: > > On Fri, 29 May 2020 at 19:56, Tony Duell wrote: > > > > On Thu, May 28, 2020 at 7:24 PM Liam Proven via cctalk > > wrote: > > > > There were also some pretty high-spec British microcomputers, but they > > tended to flop owing to the price. Things like the HH Tiger (did it > > ever go into production? Prototypes certainly exist). > > True! > > Yes, a friend has (or had) one. I have one. > He amassed a huge collection, then > sold the lot and bought a Tesla. :-) Assuming a 'Tesla' is an electric car, I'd rather be in the reverse position (selling said car and being able to buy some interesting old computers...)] > > Which were those? I thought all the Amstrad disk-based CPCs and PCWs > > could run CP/M > > When you say "disk-based" you are excluding the GSX console and the > cassette-based ones, right? Yes. CP/M I think really needs some kind of random-access storage. I guess the Epson PX8 etc ran CP/M and had (micro)cassette storage but it was a bit of kludge. So I was only considering the Amstrads with disk drives. > > The machine I referred to was the PcW 16: > > http://www.fvempel.nl/pcw16.html Ah, now that I had never come across. Thanks... -tony
Re: Microsoft open sources GWBASIC
Most languages will give you some way to shoot yourself in the foot. The
question is how much work do you need to do? In FORTRAN the easiest method
was changing the value of a literal in a subroutine call. It is standard
compliant behavior that goes back to at least FORTRAN IV. Current
compliers and converters go to pains to make sure it still happens. Not
sure if it is still present in f90 and beyond. At least modern compilers
for other languages will give you a "potential foot shooting warning",
although in C++ that warning statement could take 200 kB.
C
C CHANGE THE VALUE OF 4
C
CALL INC(4)
WRITE (*, 30) 4
30FORMAT ('2+2=',I4)
END
SUBROUTINE INC(I)
I = I + 1
END
OUTPUT
2+2= 5
Re: intellec MDS80 on eBay
That is a nice setup. With an Ice85 that is really nice. It will clearly sell for a good price. Dwight From: cctalk on behalf of Jan-Benedict Glaw via cctalk Sent: Saturday, May 30, 2020 1:28 PM To: cct...@classiccmp.org Subject: intellec MDS80 on eBay Hi! I just wanted to drop an email that there's a MDS 80 on eBay: https://www.ebay.de/itm/333612000595 (Please note: The seller, Michael, is a friend of mine, and a former coworker.) Thanks, Jan-Benedict --
Re: Microsoft open sources GWBASIC
On 2020-05-30 15:21, Fred Cisin via cctalk wrote: On Fri, 29 May 2020, Chuck Guzis via cctalk wrote: Oh, FORTRAN can do likewise--I suspect that most languages can be coaxed (perhaps with some assembly-language subroutines)to do something nasty. "A real programmer can write a FORTRAN program in any language." But, a REAL programmer, such as Chuck, can write any language program in FORTRAN. Microsoft FORTRAN-80 was actually pretty decent. I wrote a utility to transfer PDP-11 RX01-formatted floppy files to CP/M using it, but for the disk access routines themselves, which were done in M80. I still have the disk with the source code. Because F80 was uncharacteristically decent, I assumed that it wasn't really a Microsoft product. Intel FORTRAN for ISIS-II was a massive undertaking, according to the Intel folks I spoke with. Expensive, too. In addition to GWBASIC, don't forget BASCOM, the Microsoft BASIC compiler. It's top two uses were 1) a small speed improvement 2) marketing a program written in BASIC without revealing the source code. Another indication that MS really didn't know how to write compilers. At an NCC (I think; it may have been a COMDEX or WCCF--they all sort of blur together after 40-some years), a few fellows took it on themselves to benchmark BASIC compilers lurking about in the floor. Our compile-to-pcode compiler consistently beat the trousers off of BASCOM. You can see evidence of that on the web where various mini and micro BASICs were benchmarked. The 80286 port of ours came in just below a VAX 11/780 and ahead of the microprocessor crowd, including some NS32032 systems. And we were mult-user in addition. I still have my original design document printed on greenbar tractor-feed paper on a Teletype Model 40 line printer. Three of us wrote the whole thing in four months, complete with math and runtime. I have the t-shirt to prove it. Please excuse the horn-tooting, but there are a few things that I'm still proud of--and a lot of abominations that I don't want to talk about. --Chuck
Re: Microsoft open sources GWBASIC
On Fri, 29 May 2020 at 19:56, Tony Duell wrote: > > On Thu, May 28, 2020 at 7:24 PM Liam Proven via cctalk > wrote: > > There were also some pretty high-spec British microcomputers, but they > tended to flop owing to the price. Things like the HH Tiger (did it > ever go into production? Prototypes certainly exist). True! Yes, a friend has (or had) one. He amassed a huge collection, then sold the lot and bought a Tesla. :-) Wondering if I can do the same, TBH. > My experience at the time was that CP/M was not a 'big thing' in > Britain. And S100 was even less. Yes there were S100 computers here > (there were some British-produced ones like the CASU Super C which > used bought-in CPU and RAM cards and CASU I/O cards) but I don't > really remember them at the time. [Nod] > Which were those? I thought all the Amstrad disk-based CPCs and PCWs > could run CP/M When you say "disk-based" you are excluding the GSX console and the cassette-based ones, right? The machine I referred to was the PcW 16: http://www.fvempel.nl/pcw16.html (It does have a 3rd party app, ZPM, which can run CP/M programs.) I was mistaken about the PcW 10; it's a "true" PCW and can run LocoScript and CP/M: http://www.fvempel.nl/pcw10.html -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
intellec MDS80 on eBay
Hi! I just wanted to drop an email that there's a MDS 80 on eBay: https://www.ebay.de/itm/333612000595 (Please note: The seller, Michael, is a friend of mine, and a former coworker.) Thanks, Jan-Benedict --
Re: Microsoft open sources GWBASIC
Chuck, your post just reminded me of how I used FORTRAN to interface with my PDP-11 ASM routines when I was doing data acquisition as fast as possible on a MINC system. Perused my FORTRAN code about 6 months ago and had common blocks and a routine which took "arrays" which were essential chunks of PDP-11 memory that I'd use as data buffers and to access data in my ASM routines directly. Certainly a lot faster than doing function calls to get at this data but would now be looked at as very "dangerous" programming. Considering I was limited to <56 Kb of RAM for all my code and data I used a very stripped down version of RT-11 and found it simpler to create a RAMdisk out of the high memory on the 512 Kb memory card and wrote a VM driver to stash A/D data there. For this type of programming one needs to look at scalability properties of a system. That 11/23 system looks like a toy now compared to a cheap FitBit but the MINC had one job to do and needed to be pushed to its limits to do it. I documented my code well (or so I thought) but after 30+ years it took me a while to figure out what I was doing. For a dedicated system, code like that is necessary if one doesn't have the option of getting a more powerfull machine that can provide the necessary data acquisition speed as well as allowing "safe" but much slower code given the need to perform frequent checks on variables, address bounds, etc. One needs a machine that can operate in supervisor and user modes with supervisor memory protected but each context switch takes time. Used to be able to do this sort of stuff with early Windoze but everything tightly sandboxed now. Now, if I want to do any reasonable speed data acquisition have to build a microprocessor system which is fun to code and then connect it via USB to a Windoze "mainframe" for analysis. Of course, if one really wants speed, then one can use Ciarcia's "solder" programming language. Boris Gimbarzevsky On 5/29/20 3:41 PM, Fred Cisin via cctalk wrote: Yes, a pointer to the PC Interrupt Vector Table could be problematic. > > C lets you do a lot of things that some other languages will protect you > from. Accordingly, Allen Holub titled one of his books about C, "Enough > Rope To Shoot Yourself In The Foot" > ISBN-10: 0070296898 > ISBN-13: 978-0070296893 Oh, FORTRAN can do likewise--I suspect that most languages can be coaxed (perhaps with some assembly-language subroutines)to do something nasty. Two cases in point (but I have lots more). In the CDC 60-bit machines, one of the most useful functions was LOC(). It passes the address of the argument. Note that this was basically a single instruction as FORTRAN uses call-by-reference in most older versions. The other aspect of the CDC operating systems is that PPMTR looked periodically at each user's location 1 for system requests. So, it was a simple matter to use LOC() to obtain a negative subscript into an array to write and read that location. With the ability to make system requests directly (and directly address user memory), the sky is the limit. Indeed several user-written system utilities were written using just that technique. The CDC iron is word-addressable only. (Other abuses were the arbitrary target for the ASSIGNed GOTO, but that's another subject). Similarly, BASIC, depending on the version, could be abused. One technique was to use a character array with the BASED attribute (I don't know if I was the first to invent that keyword, but it was around 1978). That turned the variable into a pointer and one could change the area that the variable pointed to with the BASE...AT statement. Several utilities were written in this fashion, including a few that located the video refresh buffer and wrote to it directly. I've been known to do similar nasty things in COBOL. Side question: How does one create named COMMON in C? --Chuck
RE: Microsoft open sources GWBASIC
On Fri, 29 May 2020, Dave Wade via cctalk wrote: -Original Message- From: cctalk On Behalf Of Bill Gunshannon On 5/29/20 5:24 PM, Jim Brain via cctalk wrote: At the risk of fanning the language fire, C seems to be a smaller step up from native machine language than most other languages. It's like 80% of the portability with 20% of the effort of writing directly in ASM. Well I remember when first being introduced to "B" on the Honeywell L66 under GCOS thinking that it allowed programmers to shoot themselves in the foot in the same ways as they could with assembler, but much more rapidly. "B" was near assembler than "C" only having the "Machine Word" as a type. And before B was BCPL. BCPL was used to Bootstrap B was used to Bootstrap C. BCPL equally rapidly lets you shoot yourself in the foot.. It's fun though. I'm in the middle of creating a lttle retro project and I'm using BCPL as its "self-hosting" programming language. Gordon
Mac Performa 6214CD FTGH from San Antonio, TX (re-post; now tested)
All, Still trying to find a home for this system (re-post but with more information, testing) For the visually oriented, here are pictures showing the machine running: https://drive.google.com/drive/folders/11j__mCYOFuBAil58hAdhmSK5GMaqmcUL?usp=sharing Things in the pictures but NOT included in the giveaway are: 1) ADB cable (Mini-DIN4) (the one in the photos was borrowed from another system for testing) 2) “square” ADB mouse (also borrowed) 3) Power strip You get everything else. Mac Performa 6214CD, PowerPC CPU, 3.5” floppy and CD drive on front face Apple Extended Keyboard II (NO ADB CABLE) Apple Apple Desktop Bus Mouse II (round - not working) Apple Multiple Scan 15 Display (matching, includes cable) APS external SCSI hard drive enclosure and cable (Centronix on the hard drive end, DB-25 on the Mac end) Epson Stylus Color 740 ink-jet printer with a spare (unopened) cartridge UMAX Astra 1220S flat-bed SCSI scanner. ZIP drive with SCSI interface Cables Pile of accompanying software including at least: DeltaGraph Now Up-To-Date and Contact Sad Macs, Bombs and disasters Retrospect Backup Astra Scanner Driver All Free to a Good Home. You want this if: a) you can afford shipping or pickup from San Antonio, TX, 78254, and b) 15 years after “Take this job and shove it” came out you finally acted on it, quit your job and set up your own home office and accounting business, and now you want to relive your glory days. All items tested May 23, 2020. Everything worked, with the following exceptions: 1) The round ADB mouse included does not work. The keyboard does work and the square ADB mouse worked when plugged into it, so the fault is probably in the round mouse. 2) The printer doesn’t move any ink to the page. The ink is dried out, so I’m not at all surprised. I expect it to work with new cartridges, but did not test that. There is an unopened replacement cartridge included, so you can test at least the black printing if you open that. Replacement cartridges available at: https://www.compandsave.com/Epson_Stylus_Color_740_Ink_Cartridges_s/1396.htm under $4 each. Everything else about the printer seems to work. I hooked up to it via USB using my MacBook and software from http://gimp-print.sourceforge.net and it responds as expected for an ink-jet with dried-up ink but otherwise functional. 3) I have no ZIP cartridge to test the ZIP drive. It is recognized on the SCSI bus as a removable-media drive, power light comes on, etc, but I don’t know that it reads or writes. 4) The Mac OS 8.5 on the drive will not allow me to set the year to 2020. 5) Backup battery is dead, so the unit won’t remember dates between shutdown and startup again. 5) The door to the monitor’s controls is broken, and just taped back into place. Things that do work include the floppy drive, the CD drive (plays audio CDs), all other aspects of the computer itself and the external drive, the keyboard, and the monitor. Driver software and media for scanner and printer are included. The scanner works, I scanned an image with it and it came up clear. The glass could use cleaning, though. Please, please, please take this as a group, I really don’t want to split it up. Shipping will be challenging; if you are out of driving range but want it, contact me and we can talk. If you are in driving range and want it, let me know and we can meet half-way. Not looking to make any money, I just don’t want to throw it away and don’t want to lose money giving it away. - Mark 210-522-6025 office 210-379-4635 cell
Re: history is hard
On 05/31/2020 02:06 AM, jim stephens via cctalk wrote: On 5/30/2020 11:15 PM, Eric Smith via cctalk wrote: On 05/29/2020 02:38 PM, Noel Chiappa via cctalk wrote: Low-level machines did not even have storage protection keys, and on the /40 and /50 (I think) it was an option, although I'd guess almost any /50 had it installed. Our /50 had it and I have never seen any indication in the documentation for the hardware that indicated that it was an option. I don't think that either MVT or MFT would have been very stable without it. I certainly spent a lot of time studying how to get around it, and am responsible for a couple of SPIE patches in the MVT product from exploits trying to get into supervisor mode to muck with such. Yes, the SPIE call as supplied from IBM was surely the security hole big enough for 5 ocean liners abreast to steam right through! Everybody had to patch that, and the patch was fairly simple. But, it was a clear indication of how LITTLE IBM thought about security. Of course, they were thinking about banks where 3 teams reviewed code before it ever ran on the machine, not universities where kids would try all sorts of mischief. Yes, I know supervisor state isn't tied to the storage keys, but that was the way I went to try to circumvent the storage keys. Oh, once you have the P bit set to zero, you can do anything, such as changing the storage protection key of your own program. Jon
Re: PC Fortran (Was: Microsoft open sources GWBASIC
One reaason why you don't hear much about that is because the first version of Microsoft Fortran for the PC wasn't real great. It was written in Microsoft Pascal. On Sat, 30 May 2020, John Foust via cctalk wrote: Really! How does this connect to Microsoft's FORTRAN-80 for CP/M circa 1977? unrelated product, with no apparent connections, that I'm aware of. The 8080/Z80 FORTRAN-80 would have been a better starting point! Bob Wallace wrote the original Microsoft Pascal; I don't know who wrote the [PC] Fortran, other than being told that it was written in Microsoft Pascal, and to avoid the run-time library. On Sun, 31 May 2020, Eric Smith wrote: I assume you mean that Microsoft Fortran for the PC was written in Pascal. I did some reverse-engineering of the Microsoft FORTRAN-80 compiler, and it appears to be hand-written in 8080 assembly. On the other hand, Intel also had a FORTRAN-80 product, which was unrelated to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development systems under the ISIS-II operating system, and the compiler was written in PL/M. Exactly. Microsoft Fortran for the PC, written in Pascal, was not related to Microsoft FORTRAN-80 for CP/M, which was written in 8080 assembly. Microsoft Fortran for the PC was not related to Microsoft FORTRAN-80 for TRS80, which was a derivative of Microsoft FORTRAN-80 for CP/M, which was written in 8080 assembly. Because the TRS80 was Z80, I would not be surprised if some of the TRS80 specific code in Microsoft FORTRAN-80 for TRS80 might have used some Z80. Microsoft Fortran for the PC was written in Pascal. It was an unrelated product. I don't think that any of the Microsoft Fortran products were related to the Intel FORTRAN-80. Did Microsoft ever develop anything in PL/M? Did Microsoft ever develop anything for ISIS-II?
Re: history is hard
On 5/30/2020 11:15 PM, Eric Smith via cctalk wrote: On 05/29/2020 02:38 PM, Noel Chiappa via cctalk wrote: Low-level machines did not even have storage protection keys, and on the /40 and /50 (I think) it was an option, although I'd guess almost any /50 had it installed. Our /50 had it and I have never seen any indication in the documentation for the hardware that indicated that it was an option. I don't think that either MVT or MFT would have been very stable without it. I certainly spent a lot of time studying how to get around it, and am responsible for a couple of SPIE patches in the MVT product from exploits trying to get into supervisor mode to muck with such. Yes, I know supervisor state isn't tied to the storage keys, but that was the way I went to try to circumvent the storage keys. thanks Jim
Re: PC Fortran (Was: Microsoft open sources GWBASIC
On Sat, May 30, 2020 at 3:27 PM Fred Cisin via cctalk wrote: > >> One reaason why you don't hear much about that is because the first > >> version of Microsoft Fortran for the PC wasn't real great. > >> It was written in Microsoft Pascal. > > On Sat, 30 May 2020, John Foust via cctalk wrote: > > Really! > > How does this connect to Microsoft's FORTRAN-80 for CP/M circa 1977? > > unrelated product, with no apparent connections, that I'm aware of. The > 8080/Z80 FORTRAN-80 would have been a better starting point! > Bob Wallace wrote the original Microsoft Pascal; I don't know who wrote > the Fortran, other than being told that it was written in Microsoft > Pascal, and to avoid the run-time library. > I assume you mean that Microsoft Fortran for the PC was written in Pascal. I did some reverse-engineering of the Microsoft FORTRAN-80 compiler, and it appears to be hand-written in 8080 assembly. On the other hand, Intel also had a FORTRAN-80 product, which was unrelated to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development systems under the ISIS-II operating system, and the compiler was written in PL/M.
Re: history is hard
On Fri, May 29, 2020 at 3:30 PM Jon Elson via cctalk wrote: > On 05/29/2020 02:38 PM, Noel Chiappa via cctalk wrote: > > > From: Jon Elson > > > > > As far as I know, there was no VM/360. There WAS VM/370, which > was out > > > in the early 1970's > > > > CP/67, which was a semi-product, and ran only on 360/67's, was basically > the > > same functionality as VM/370. (I get the impression that the code was > > descended from CP/67, but I can't absolutely confirm that > I think it was, too. But, only a /67 could run this. Any > other 360 would have big security/reliability problems if > they tried to implement this kind of virtualization. > Low-level machines did not even have storage protection > keys, and on the /40 and /50 (I think) it was an option, > although I'd guess almost any /50 had it installed. And, > the storage protection keys were a very coarse/crude tool, > although you could set up > sharable read-only areas. > The issue wasn't whether the machine had storage keys (protection, SSK and ISK instructions). AFAIK CP/67 didn't use that even when available. What CP/67 and VM/370 required was Dynamic Address Translation (DAT), and the 360/67 was the ONLY 360 model for which that was available. Contrary to popular belief, DAT wasn't even available on every 370 model, as it was an optional feature of the 370 architecture. CP/40 was developed on a modified 360/40 that had DAT (with the addition of a "CAT box"), but was never available as a product.
