The old computers thread

Ugh, although I would like to do conspiracy stuff as for sure Microsoft did them (a plenty) I don't think they had power or the need to do anything of the sorts.

There are many angles to this story. I think these are most relevant

- BASIC is o.g. PC DOS tech, meaning, real mode, entire address space (and thus config space/VRAM) accessible to any code. In order to actually make PC graphics performant, VESA moved graphics into larger address/data space of the 386 bus in late 80s. At this point the true IBM PC architecture was dead, all that was left were compatibility parts. 386 was the future and to exploit it one uses protected mode which allows for far larger, faster bus, that can have 32 bit data path and 32 bit addressing (limits that served us for next 20 years).

- ISA, that is straightforwardly programmed from DOS, might have been buffed up in frequency and number of data lines to allow performance for high-resolution graphics. However, the ISA side still implies mapping all configuration and data in the 1 MB address space because the 16 MB one of 24-bit address lined 16-bit ISA is not accessible from real mode. Furthermore, PC uses segmented memory and thus no chunk larger than 64kB can be addressed in memory.

- VESA as a standard is accessible from QBasic/DOS by virtue of being present on the ISA. Limits from paragraph above apply. The VESA 2.0/3.0 commands are performed by standard ISA register I/O. The large, maybe even in megabytes large framebuffer is acessed by banking the 64kB A000 mapped VGA area via register, to point to another region of VRAM. So its doable. But to have performant graphics, you need to avoid ISA, and the "alternative" eg the cutting edge was VLB and PCI, not accessible under real mode

- "not accessible under real mode" comes with a caveat. Not all DOS is 16 bit. Extenders are used to kick the CPU into 386 protected mode and access the entire memory of the platform. One of your points was no 3D in BASIC...for compiled BASIC at least theoretically you could use an extender, and you could link in one of the early 3D APIs available for earliest PCI 3D cards. But this implies you have a 386 PC to begin with.

- the smoking gun as bots would say; PC, the entire ecosystem, has nothing to do with gaming until 1993. In no point of time before that year, has anyone in power ever considered gaming for anything as a requirement. The CPUs, the bus, the graphics standards, they were all for business. When IBM designed VGA they didn't bat an eye at what Atari/Amiga/Nintendo or the arcades were doing.

So the conclusion would be that VESA/3D tech belongs to 32 bit "Windows" era already, so no space for Microsoft to leave something behind when it already is?
 
My introduction to programming wasn't it tho. It was shell first, simple batch files, then at lower grades of elementary school we had Logo, the turtle graphics system. Turtle is a pen and one inputs commands to draw something. Very nice for kids to get something visual out of it immediately. So there is a point when you stop writing "CAD" commands and advance to programming e.g. define variables, make loops and conditionals and construct some sort of a program flow. Logo I had was simple from the 80s, 320x200 graphics, clumsy CGA font with only 4 lines of text on screen. I think I just moved to GW BASIC because it was there and it just allowed better "IDE" with 80 lines for editing.
 
I'm not much into old computers - except Lisp machines.

The Unix+C world is OK, and reasonably productive.

It is nothing compared to what Common Lisp and some of the Lisp machines offered.
 
The Unix+C world is OK, and reasonably productive.

It is nothing compared to what Common Lisp and some of the Lisp machines offered.

In my opinion, a bad offer. You get the capacity to write high level programs against hardware that understands high level programming. At a cost of an arm and a leg. It never left academic circles because it was commercially totally unfeasible. I get from programmers perspective that it was a joy, but for me it is like asking to sit on a 100.000 euro chair to be an optimal developer.

It's too much accentuated IMO due to GNU/FSF culture. Symbolics and Lisp Machines were small companies. They did not employ hordes of hardware devs. They were not a threat to anyone. They were gone as soon as 68020 and 386 got adopted.

For me it is an interesting story how academia/software bubbles can happen even when there are highly intelligent people involved. Exactly under what pretense did they assume they could ever put a CPU arch 32+ bits with tons of features and extremely lean and polished cycle-efficient ISA (instruction set arch) in the 80s when Intel could not do so and failed hard with iAPX 432, when Motorola couldn't deploy even a hybrid 16/32 CPU in enough numbers until the mid 80s.

Heard this fairytale back in the early 00s when Java got popular and MS decided to go with .NET, swaths of seniors of Microsoft dev technologies ensuring me that we are going to have CPUs that run bytecode in a hardware level VM in 10 years time, because it is so good for software development.
 
In my opinion, a bad offer. You get the capacity to write high level programs against hardware that understands high level programming. At a cost of an arm and a leg. It never left academic circles because it was commercially totally unfeasible. I get from programmers perspective that it was a joy, but for me it is like asking to sit on a 100.000 euro chair to be an optimal developer.

It's too much accentuated IMO due to GNU/FSF culture. Symbolics and Lisp Machines were small companies. They did not employ hordes of hardware devs. They were not a threat to anyone. They were gone as soon as 68020 and 386 got adopted.

For me it is an interesting story how academia/software bubbles can happen even when there are highly intelligent people involved. Exactly under what pretense did they assume they could ever put a CPU arch 32+ bits with tons of features and extremely lean and polished cycle-efficient ISA (instruction set arch) in the 80s when Intel could not do so and failed hard with iAPX 432, when Motorola couldn't deploy even a hybrid 16/32 CPU in enough numbers until the mid 80s.

Heard this fairytale back in the early 00s when Java got popular and MS decided to go with .NET, swaths of seniors of Microsoft dev technologies ensuring me that we are going to have CPUs that run bytecode in a hardware level VM in 10 years time, because it is so good for software development.

Well, the Lisp machines were never mass produced. Obviously they couldn't compete on price.

That doesn't change anything about the utter superiority of the software, especially for development.
 
It doesn't and the fact stands Lisp paradigms and Lisp machine design were influential.
I worked about a year on GnuPG suite, equipping it to be able to do KEM/PQC SMIME email. Gpg does not deal with X509 but they have their own format in S-expressions. I like them very much and its a "piece" I intend to reuse in another C projects, especially for configuration. On the other hand X509 with ASN.1 BER/DER stuff comes from 80s telco and it is really really good format for network portability.
Interestingly from programmer's perspective sexp is a far far more handy, you could say superior tech, but you're not going to be able to achieve perfect bitwise wire encoding as 'easily' as with ASN.1

Previously about a decade ago I owned a couple of million LOC C project a high performance network I/O machine capable of running in hundreds of GB/s on x86-64 servers, the high parts of the business logic were defined in LISP dialect used as a DSL and compiled directly to C.

The point of what I said above is in depreciation of Lisp machine concept the moment the CPUs got generally so fast they could brute force it, compilers could emit extra instruction prologues and epilogues for data type checking and runtime correctness, without visible penalties. Same thing happened with Amiga/Atari and 16-bit home consoles vs the PC. Doing special chips to handle video/audio had merit, until affordable PCs became so fast that you could make 75% fidelity effort in games just by programming a general business PC.
 
The point of what I said above is in depreciation of Lisp machine concept the moment the CPUs got generally so fast they could brute force it, compilers could emit extra instruction prologues and epilogues for data type checking and runtime correctness, without visible penalties. Same thing happened with Amiga/Atari and 16-bit home consoles vs the PC. Doing special chips to handle video/audio had merit, until affordable PCs became so fast that you could make 75% fidelity effort in games just by programming a general business PC.

The Lisp machine hardware is not needed anymore of course. A compiler like SBCL makes code that runs well on "normal" CPUs and I hear that even PCs have mice now.

But the capability step-back in operating system and development environment is still painfully obvious. Symbolics Genera had an integrated environment where the editor, the IDE and the OS were all Common Lisp. Although there are some Common Lisp written editors around they don't have the wide IDE support that SLIME has. So Common Lisp hackers are stuck with a 3-language split - Common Lisp for the programs, Emacs Lisp for the editor and IDE and a C-interfaced OS.

People can't wait for Genera to be open sourced.
 
Back
Top