[cctalk] Re: Random items on Pascal #3
On 5/10/24 16:37, Fred Cisin via cctalk wrote: > I was told that some of the many locally applied patches were done by > writes to array elements with negative subscripts. > CDC 6000 (the one with PPUs) OS (SCOPE, KRNONOS, MACE and NOS) used a single PPU that, among other things, monitored the contents of location 1 in each control point's field length. Normally, it was zero; but if it became nonzero, it took the format of a system request, very often to be serviced by a certain PPU program. In CDC FTN (and probably RUN), you could get the (60 bit word) address of a variable using either the LOCF() function call or .LOC. unary operator, depending on the dialect of FORTRAN. So, to put something into that location 1 address word was pretty straightforward. INTEGER AX(1), IX; IX = LOCF( AX) AX ( -IX-1) =
[cctalk] Re: Random items on Pascal #3
On Fri, 10 May 2024, Charles via cctalk wrote: Regarding protections, it didn't have many. I remember spending a day tracking down a fatal bug with a logic analyzer (emulators were still a dream in this small company)... another programmer had used an array subscript out of range and the compiler didn't catch it for some reason. So in this array defined [0..20], when the typo caused a write to FOO[60] instead of FOO[20], bad things happened. Ah, the good old days ;) At Goddard Space Flight Center, my position was negligible (gopher and APL and FORTRAN programming for a British pysicist studying the Van Allen belts). I was told that some of the many locally applied patches were done by writes to array elements with negative subscripts. We may have been the first one to get some IBM 360 operating systems. I remember one time, shortly after "upgrading", we rolled back to the previous one, until the next one arrived. -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: Random items on Pascal #3
In the early '80's, I did some programming with Micro Concurrent Pascal, on embedded CDP1802 systems. It was really nice to be able to program in something other than assembly language (a cross-assembler that ran on a PDP-11 system). Regarding protections, it didn't have many. I remember spending a day tracking down a fatal bug with a logic analyzer (emulators were still a dream in this small company)... another programmer had used an array subscript out of range and the compiler didn't catch it for some reason. So in this array defined [0..20], when the typo caused a write to FOO[60] instead of FOO[20], bad things happened. Ah, the good old days ;) -Charles
[cctalk] Re: CORRECTIONS Re: DOS p-System Pascal:
Microsoft had to pay $120 million, and Stac had to pay $13.6 million. But Microsoft also settled some claims out of court with a $39.9 million dollar investment in Stac, and paid $43 million in royalties. Yes, billg had a bad day. comparable to my losing $100 On Fri, 10 May 2024, Sellam Abraham via cctalk wrote: I was going to say, if it was only $100K then old Billy Boy would've laughed all the way out of court and on the way home. Yes, as soon as I sent that, I knew that I had screwed up. I remember the Stac lawsuit. It was just another company actually doing innovation whose technology Microschlock tried to appropriate in its typically and despicably underhanded ways. Stac was one of the few (only?) companies to come out pretty well after "partnering" with MS. Too much proprietary information shared too early in the negotiations. The award was based on "$5.50 per copy", . . . When Seattle Computer Products, who had a royalty-free license to sell MS-DOS, was on the rocks, and MICROS~1 was terrified of somebody like AT getting that, they did the right thing, and simply BOUGHT the company. As always seems to happen in these kinda cases (just like Word and Mac), it was never adequately spelled out whether "The operating system" meant version 0.9, or all versions including current, and what products, such as Windoze could be construed to be derivative products. -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: CORRECTIONS Re: DOS p-System Pascal:
On Fri, May 10, 2024, 3:38 PM Fred Cisin via cctalk wrote: > > Microsoft had to pay $120 million, and Stac had to pay $13.6 million. > But Microsoft also settled some claims out of court with a $39.9 million > dollar investment in Stac, and paid $43 million in royalties. > Yes, billg had a bad day. comparable to my losing $100 > I was going to say, if it was only $100K then old Billy Boy would've laughed all the way out of court and on the way home. I remember the Stac lawsuit. It was just another company actually doing innovation whose technology Microschlock tried to appropriate in its typically and despicably underhanded ways. Stac was one of the few (only?) companies to come out pretty well after "partnering" with MS. Sellam
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On 2024-05-10 1:01 p.m., Chuck Guzis via cctalk wrote: There have been some minor skirmishes in the MCU world over what language should be used when programming. EASY! OCTAL! If it worked on the 8 it is good enough for me. C/C++ is very much top dog, probably because the development suites are written for that. There's a small group that advocates Python; and some say that Ada is best. But they represent a very small segment. --Chuck I think it is more the case UNIX was around, and written in assembler. The egg. Then we got B, a Archaeopteryx and flock of chickens that all start with C. C generates real code output and not some virtual machine, another important factor as well as having bit fields and structures. The late 70's , early 80's where the golden years of computing. C,Pascal and PL/M are the only big names for 8 bit cpu's, and what came later.
[cctalk] Re: CORRECTIONS Re: DOS p-System Pascal:
Please note, that I am NOT saying that there was nothing wrong in the compression. Merely that the disasters that prompted the public outcry were due to SMARTDRV's problems, not the problems with the compression. My numbers were all wrong on the Microsoft V Stac lawsuit. Micorsoft and Stac had looked at each others code as part of alicensing negotiation, that fell through. Microsoft had to pay $120 million, and Stac had to pay $13.6 million. But Microsoft also settled some claims out of court with a $39.9 million dollar investment in Stac, and paid $43 million in royalties. Yes, billg had a bad day. comparable to my losing $100 IBM's PC-DOS 6.10 had a similar bundle list to MS-DOS 6.00, but each product from a different vendor than Microsoft's On Fri, 10 May 2024, Fred Cisin via cctalk wrote: . . .
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On 5/10/24 14:44, Doug Jackson via cctalk wrote: > C didn't enter my world until I started running FreeBSD in the late 90's > where it was essentially part of the OS. I remember paying $600 bucks AUD > for a Borland C compiler running under Windows, but the whole concept of > writing a simple app was insane. As of about 1984, Microsoft recommended Lattice C. (Still have my two-floppy compiler). One had to be keenly aware of the architecture and what the compiler was doing, but at least it was easier than assembly and a bit more portable. Various C implementations, like 1960s FORTRAN implementations, could be all over the map. It wasn't until C90 that we had some sort of real standard. I remember that on Usenet, in the early 80s, I think it was Brian Kernighan ran a newsgroup for C (could have been Dennis Ritchie). One of the infrequent posts I recall was "What does this statement do?". There were several "Undefined" situations. --Chuck
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
Circa 1986 I was working at the Research School of Physical Sciences at the Australian National University. As late as that we were still running CP/M on an eclictic mix of Imsai8080 and STD Bus based machines. These were all running laboratory experiments. Turbo Pascal was king in that environment. C compilers were just way too weird to even consider. Even when we started rilling out IBM PC's in about 1988, we still used Turbo Pascal. Re compiling apps for the new platform was magic... When I left there and moved into a small packet switching hardware developed in the mid 90s, we used Turbo pascal for the PC side of any interface, and Cross compiled C for the 68000/010/020 based hardware plug in line controllers. Everything was hosted in a custom VME rack system running Unix. C didn't enter my world until I started running FreeBSD in the late 90's where it was essentially part of the OS. I remember paying $600 bucks AUD for a Borland C compiler running under Windows, but the whole concept of writing a simple app was insane. Now I use C and C++ regularly for small microcomputers, but still not on my CP/M systems. Doug On Sat, 11 May 2024, 5:01 am Chuck Guzis via cctalk, wrote: > There have been some minor skirmishes in the MCU world over what > language should be used when programming. > > C/C++ is very much top dog, probably because the development suites are > written for that. > > There's a small group that advocates Python; and some say that Ada is > best. But they represent a very small segment. > > --Chuck > >
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
very slow and buggy. I heard a story that to speed up disc access, MS put FAT-manipulation code in the actual compiler and that occasionally destroyed the FAT. Sorry Stuff, ain't so. If you had FAT corruption issues, perhaps you had SMARTDRV enabled with write cacheing (which did occasionally mess up the FAT). On Fri, 10 May 2024, Sellam Abraham via cctalk wrote: I developed quite a bit and for many years with Microsoft C v6.0 under DOS and it was not bad. The compiler was decently fast and once 486s and then Pentiums became available compile time wasn't really an issue. It was actually the least shitty Microsoft product I've ever used, next to MS-DOS 6.22. It was actually pretty good. A good example of why I generally hate MS software. But the solution was easy: just turn off write-caching. I also liked their C V6. and MASM 5.00 and beyond were the first MASM to have documentation that was not CRIMINALLY bad. SMARTDRV caused a lot of disk corruption. Which was erroneously blamed on the compression. When Infoworld did a test routine that did a bunch of miscellaneous stuff and rebooted in a loop (thereby corrupting disk because SMARTDRV write cache had not been written out!) and blamed the compression, billg tried to explain that their test routine was faulty, not the compression, but wasn't about to admit that SMARTDRV was at fault. Infoworld reported that conversation as an attempt to intimidate! MS-DOS 6.2x "fixed the problems with compression"! The way that it did so was to change SMARTDRV to NOT default to write-cacheing on, IFF the user turned SMARTDRV write-cacheing back on, then SMARTDRV was changed to NOT re-arrange the sequence of writes (had been for efficiency, but risky), and NOT display the DOS prompt until the write cache(s) were written. (thus not implicitly telling the user that it was now OK to turn off the computer (which had a shutdown sequence of turn off the power)) Those changes to SMARTDRV "fixed compression". MS-DOS 6.2x also did a LOT of other fixes; it may have been the only Microsoft product where the primary goal of the updaate was to improve reliability! MS-DOS 6.20 SMARTDRV and other fixes MS-DOS 6.21 6.20 without compression; Microsoft had lost lawsuit with STAC ($100K judgment from Microsoft to STAC, and $30K judgement from STAC to Microsoft. billg said, "I'm having a bad day.") MS-DOS 6.22 6.20 with a new non-infringing compression -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On 5/10/24 14:03, Sellam Abraham via cctalk wrote: > On Fri, May 10, 2024 at 1:36 PM Fred Cisin via cctalk > wrote: > I developed quite a bit and for many years with Microsoft C v6.0 under DOS > and it was not bad. The compiler was decently fast and once 486s and then > Pentiums became available compile time wasn't really an issue. It was > actually the least shitty Microsoft product I've ever used, next to MS-DOS > 6.22. It was actually pretty good. Same here. And it only took MS about 5 revisions before ML/MASM was dependable. :) --Chuck
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
> From: Fred Cisin via cctalk [mailto:cctalk@classiccmp.org] > Sent: Friday, May 10, 2024 4:36 PM > To: Stuff Received via cctalk > Cc: Fred Cisin > Subject: [cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M) > > Sorry Stuff, ain't so. > > Bob Wallace wrote the Microsoft Pascal compiler, while he was at > Microsoft. He was their tenth employee. He told me that their runtime > library (which he didn't write) is buggy and slow. > So slow that it made benchmarks with their Fortran compiler (which also > used the buggy and slow runtime library), perform SLOWER than interpreted > BASIC. > > > But, it certainly did NOT do anything to the disk; certainly no messing > with the FAT. > > If you had FAT corruption issues, perhaps you had SMARTDRV enabled with > write cacheing (which did occasionally mess up the FAT). > > -- > Grumpy Ol' Fred ci...@xenosoft.com I wrote SW with MS Pascal for an accelerometer experiment on the Space Shuttle using DOS on an 8086 Multibus system (OARE). MS Pascal supported a modifier for procedures named "Interrupt" that was supposed to be used for Interrupt Service Routines, problem was they forgot to push and pop the register set before and after entry. It didn't work very well. IIRC, we had to create an assembly macro at entry and exit to do the register saves and restores. DOS, of course, is/was not reentrant, so no DOS services could be used in the interrupt code. The SW worked well, but was on Columbia when it was lost on reentry. The flight spares for that program ended up going on the ISS, with a different system I ported to a PC-104 80486 system in C under VxWorks (MAMS) that had been in use for 20 years until it was brought back down for refurbishment. Gary
[cctalk] Re: Programming languages; Was: DOS p-System Pascal
While doing my customary "whatever happened to" sweep, I ran across this paper of Jules Schwartz (he of JOVIAL) A refreshingly frank evaluation from the author from 1978. http://jovial.com/documents/p203-schwartz-jovial.pdf (Tidbit: The "J" in JOVIAL does stand for "Jules'", but was not of his doing--rather, he relates that it was done behind his back.) Just on the subject of "languages and how we got here." --Chuck
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On Fri, May 10, 2024 at 1:36 PM Fred Cisin via cctalk wrote: > On Fri, 10 May 2024, Stuff Received via cctalk wrote: > > I recall that MS sold a Pascal compiler, possibly from someone else. It > was > > very slow and buggy. I heard a story that to speed up disc access, MS > put > > FAT-manipulation code in the actual compiler and that occasionally > destroyed > > the FAT. > > Sorry Stuff, ain't so. > > Bob Wallace wrote the Microsoft Pascal compiler, while he was at > Microsoft. He was their tenth employee. He told me that their runtime > library (which he didn't write) is buggy and slow. > So slow that it made benchmarks with their Fortran compiler (which also > used the buggy and slow runtime library), perform SLOWER than interpreted > BASIC. > I developed quite a bit and for many years with Microsoft C v6.0 under DOS and it was not bad. The compiler was decently fast and once 486s and then Pentiums became available compile time wasn't really an issue. It was actually the least shitty Microsoft product I've ever used, next to MS-DOS 6.22. It was actually pretty good. > If you had FAT corruption issues, perhaps you had SMARTDRV enabled with > write cacheing (which did occasionally mess up the FAT). > A good example of why I generally hate MS software. But the solution was easy: just turn off write-caching. Sellam
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On Fri, 10 May 2024, Stuff Received via cctalk wrote: I recall that MS sold a Pascal compiler, possibly from someone else. It was very slow and buggy. I heard a story that to speed up disc access, MS put FAT-manipulation code in the actual compiler and that occasionally destroyed the FAT. Sorry Stuff, ain't so. Bob Wallace wrote the Microsoft Pascal compiler, while he was at Microsoft. He was their tenth employee. He told me that their runtime library (which he didn't write) is buggy and slow. So slow that it made benchmarks with their Fortran compiler (which also used the buggy and slow runtime library), perform SLOWER than interpreted BASIC. But, it certainly did NOT do anything to the disk; certainly no messing with the FAT. If you had FAT corruption issues, perhaps you had SMARTDRV enabled with write cacheing (which did occasionally mess up the FAT). -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On Fri, 10 May 2024 12:00:07 -0500 cctalk-requ...@classiccmp.org wrote: > The UCSD shell was atrocious. The compiler was slow. The editor was > terrible. The entire experience was reminiscent of working on a dumb > terminal connected to a mainframe, when it could've taken advantage of > the features of the personal computer. > > I hated it. > > I hate it. I've never had the pleasure, but a glance over the documentation is... enlightening. God only knows why so many people over the decades have gravitated to the "pick the thing you want to do from this list of the things which can be done" school of UI design...
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
There have been some minor skirmishes in the MCU world over what language should be used when programming. C/C++ is very much top dog, probably because the development suites are written for that. There's a small group that advocates Python; and some say that Ada is best. But they represent a very small segment. --Chuck
[cctalk] Re: DOS p-System Pascal: (Was: Saga of CP/M)
On 2024-05-09 09:46, Warner Losh via cctalk wrote: On Thu, May 9, 2024, 5:39 AM Bill Degnan via cctalk wrote: Without doing the research before asking, there was the UCSD p-System Pascal for IBM PC which came out very early in the history of the IBM PC. It was not very popular. The SAGE II that had native Pascal (68000) was not a popular machine. Waterloo Pascal on the SuperPetPascal never really made it on the microcomputer platform did it? Not until TurboPascal... But it was only a few years until C emerged from the language "street fight" as top dog... depending on what the universe of microcomputers we're talking about. I recall that MS sold a Pascal compiler, possibly from someone else. It was very slow and buggy. I heard a story that to speed up disc access, MS put FAT-manipulation code in the actual compiler and that occasionally destroyed the FAT. S.
[cctalk] Re: Random items on Pascal #4
After 'lunch with Draper', you almost immediately reference a 'CRUNCH' utility? Seems like more than coincidence to me, but I'm big on conspiracy theories.
[cctalk] Re: Random items on Pascal #3
On Fri, May 10, 2024 at 8:45 AM Paul Koning via cctalk wrote: > I suppose you could pose ESPOL as an example of a language for a machine, ESPOL was likely a major inspiration for SPL (System Programming Language) for the Classic stack-based HP 3000 which was used to write the MPE operating system (there was also no separate assembly language). The constructs in SPL map pretty much directly onto the hardware features, and it has an ASSEMBLE(...) statement for in-line machine code which is used frequently because an SPL programmer knows what's happening at the machine level and sometimes you just want to ASSEMBLE(SWAP, DUP) etc. SPL was a very machine-specific language designed explicitly for its machine. It was picked up by Tandem (perhaps literally off someone's desk when they weren't looking) to create TAL which was used to develop Tandem's original NonStop operating system for their machine which was, er, "inspired" by the original HP 3000 design. Later when HP migrated MPE to PA-RISC, there were eventually two different PA-RISC SPL compilers developed, one (SPLash!) by Allegro Consultants, and one internally by HP that was used to migrate the TurboIMAGE DBMS to native code (after their attempt to replace it with a new HP IMAGE based on a relational kernel crashed and burned),
[cctalk] Re: Random items on Pascal #3
> On May 10, 2024, at 11:16 AM, Sellam Abraham via cctalk > wrote: > > On Fri, May 10, 2024, 7:53 AM Chuck Guzis via cctalk > wrote: > >> There's a third class that I haven't (yet) mentioned. Design a machine >> to solve a particular problem or class of problems. Saxpy was such a >> machine; we have bitcoin ASICs and our latest AI ventures. >> >> What was the CM-1 programmed in? >> >> --Chuck >> > > Of course, there's the Manchester Baby. > > Sellam And SAGE. paul
[cctalk] Re: Random items on Pascal #3
On Fri, May 10, 2024, 7:53 AM Chuck Guzis via cctalk wrote: > There's a third class that I haven't (yet) mentioned. Design a machine > to solve a particular problem or class of problems. Saxpy was such a > machine; we have bitcoin ASICs and our latest AI ventures. > > What was the CM-1 programmed in? > > --Chuck > Of course, there's the Manchester Baby. Sellam > >
[cctalk] Re: Help request with fundraising campaign to save historic computers
On Sat, 4 May 2024 at 17:28, Gianluca Bonetti via cctalk wrote: > > I am helping Museo del Computer with this fundraising effort in order to > save a large number of machines with significant historic value, including > some Sperry Univac systems. I shared the links on Vintage Computer Club on Facebook, but I agree: you need an English language website, and an English language project description, if you want to raise money internationally. The websites did not successfully go through Google Translate, although the Museo homepage did in Firefox, oddly enough. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
[cctalk] Re: Random items on Pascal #3
On 5/10/24 06:44, Paul Koning wrote: > > As for "language to the machine" that's pretty much unheard of. While there > certainly are languages that only were seen on one or a few machines or > architectures -- SYMPL, CYBIL, BLISS, TUTOR -- it isn't because that was the > intent of those languages. I suppose you could pose ESPOL as an example of a > language for a machine, though I suspect it could have been generalized, as C > was, if there had been a desire to do so. There's a third class that I haven't (yet) mentioned. Design a machine to solve a particular problem or class of problems. Saxpy was such a machine; we have bitcoin ASICs and our latest AI ventures. What was the CM-1 programmed in? --Chuck
[cctalk] Re: Random items on Pascal #3
> On May 9, 2024, at 8:58 PM, Chuck Guzis via cctalk > wrote: > > On 5/9/24 16:30, Michael Thompson wrote: >> I have a source code tape for Pascal on a CDC 6600 from CDC in France. >> I am not sure which version it is. > > Broadly speaking, there were only three major CDC versions; the 1972 > original, the 1975 rewrite, and the (I think) 1980s version. There were > intermediate versions, of course. > > I think that the 1975 version was widely used as a reference for many > other implementations. > > But now comes the question, "Does one design a machine to a language or > a language to a machine?" If you take the former course, you have the > problem of not being able to implement features that the language > designers didn't imagine. In the latter case, you wind up with a > language that isn't easily made portable. Or neither. "Machine to a language" can be seen in the Burroughs mainframes (ALGOL-60), in the IBM 360 (Fortran and COBOL) and perhaps some others. But a lot of machines are not built to a particular language, certainly that's the case for most if not all modern machines. Some machines might have features to optimize certainly languages while still being quite general; the "display" support in the Electrologica X8 is an example, but it is just as happy running Fortran or LISP. As for "language to the machine" that's pretty much unheard of. While there certainly are languages that only were seen on one or a few machines or architectures -- SYMPL, CYBIL, BLISS, TUTOR -- it isn't because that was the intent of those languages. I suppose you could pose ESPOL as an example of a language for a machine, though I suspect it could have been generalized, as C was, if there had been a desire to do so. paul
[cctalk] Re: New VCF Video bumper
First one. Sounds vintage, is not musically annoying like most of the others, and has a nice easter egg in it. Marc > On May 9, 2024, at 12:31 PM, John Herron via cctalk > wrote: > > Do you know who your demographic or age is that you're trying to attract to > watch the videos? > >> On Fri, May 3, 2024, 10:45 PM Jeffrey Brace via cctalk < >> cctalk@classiccmp.org> wrote: >> >> The Vintage Computer Federation is looking for a new bumper to add to the >> front and back of all their new videos. >> There are 7 different versions. Vote on the one that you like best! >> >> https://forms.gle/Y9Qrj26xokeFXjub6 >>
