The Mega ST keyboard is indeed the best keyboard of the whole Atari family. My TT keyboard has its rubber dome getting stiff with age. This said, the Mega ST keyboard has one big flaw, its plastic is getting extremely brittle and fragile with age. I had one keyboard drop 1m (3ft) to the floor and it exploded like a glas vase. So if you have a Mega ST keyboard, be very careful to handle it gently.
The expansion slot of Mega-ST is just 2 rows of 32 pins that are 1:1 connected to the CPU pins. Any extension that was supposed to be solderedon the CPU could be put in the slot with a simple adapter (see f.ex. the Volksfarben ISA slot adapter for ET4000 VGA cards).
I bought a Mega ST2 because I studied CS and wanted to become a developper. I sold the Amiga 500 my father had bought me. The ST was cheaper for programming than the Amiga 500 as you would need to add, at least a second floppy and a lot of memory. Furthermore, I hated Workbench the GUI of the Amiga (for the same reason I hated also Windows 3.1, you had to use a special program to access the files on the drives, you had icons in the windows only if you had drawn specifically a special icon, I preferred how on GEM and the Mac Finder, windows would directly show what's on the disk).
The big advantage we had on Atari and Amiga was that the 68000 could address more than 640K without a sweat. PC's had this annoying limit up until the 90s and the complexity that it introduced was mind blowing (EMM, EMS, XMS etc.).
In 87 when I was student at University, I managed to write all my sofware on the Mega ST2 and print my papers with Signum! on my 9 pin matrix printer in a quality that my PC colleagues were absolutely jealous of. As said, the advantage was then quickly lost even if I still could use my 1991 acquiered TT up until the mid 90. But by then, the PC was indeed already in another category (CD-ROM, SVGA, Soundcards, Win95 and/or NT or OS/2, beginning of Linux etc.). Our poor niches computer couldn't follow against the sheer mass of the market.
OP's grievances are spot on for the period 1985 to 1990. After that, PC's did indeed gain enough power (386 were mass and 486 just came out), also VGA started to become. This means that your perception built especially after 1990 is right but doesn't contradict OP's list as Atari's and Amiga's were indeed much much more advanced and useful than XP's and 286 under MS-DOS/CGA.
normal 720 K floppies were very generous with the sectors on a track. It was easy to format a floppy with 10 sectors per track even without reducing the gap between sectors. On Atari it was almost standard praxis which made that floppies had generally 800K capacity. It was even possible to squeeze 11 sectors per track by reducing the inter-sector gapto a minimum. Furthermore, most floppies allowed to write on track 81 and 82 (sometime even 83). So it was possible to have floppies with up to 902K capacity (not a good idea in the long run, I recently tested such a floppy I had made 30 years ago and it had a lot of read errors athing that 720K and 800K do not).
You're probably meaning the Belgian designed DAI computer that was developed for TI initially but was then refused in favor of the TI-99/4. From a corporate point of view it made sense as the DAI was architected around a Intel 8080A. TI-99/4 had the advantage of using much more exclusive TI parts (CPU, Video, sound, I/O, GROM, etc.).
It's a pity that the DAI then could not gain market shares as it was a very interesting and capable computer. It had graphic capabilities that only later 16 bit computer could reach (Amiga, ST), had a semi-compiled BASIC that was fast, even on the quite slow 2MHz 8080, it could use an arithmetic co-processor (AMD 9511), it also had genlock which allowed to mix TV signals with its graphics (long before Amiga), etc.
One thing TI (Extended) Basic had for it that was almost unique among early home computers was its use of decimal floating point with 13 digits precision. It was so useful for maths. I used it a lot at that time in high school. When I switched to an Apple II with its 5 byte binary floats, man was it a disappointment. It was faster, yes, but, boy oh boy, what a catastrophic loss of precision.
The fundamental issue with BASIC on the TI-99/4A, be it the regular BASIC or even the Extended BASIC, is that the program was stored in the video memory. This meant that you couldn't use all features of the VDP, you could only use a limited number of tiles (96 afaicr), you could not use other graphics mode, raster interrupts and sprite multiplexing, forget it. The games on cartridges were not limited to that and could use up to 24K (afaicr) of machine code + a lot of GROM.
One needs only to look at what a Coleco console or a MSX1 could do with a system that didn't use the graphic chip for what it was not intended to be.
You can also visit one in Germany at the Technik Museum Sinsheim[1]. It has the advantage that it can be compared to the soviet counterpart Tupolev Tu-144 that is also exposed.
Not many characters left in ASCII. Reuse of an existing operator almost required.
Binary operators cannot be use as it would be grammatical ambiguous and would need resolution at the semantic pass which is a big no-no (that's why C++ is so slow at compiling, it cannot be parsed without semantic analysis). This left only the two exlusively unary operators !, ~. As ~ was repurposed for string concatenation, only ! remained.
templ!thing(a,b)
I would have thought that templ(thing)(a,b) would have been a good solution, as it is what is used in the declaration/definition side of templates, but this would have made removing redundant () not possible in UFCS expressions.
6502 is nice to program in assembler. For a compiler it is an atrocious platform to support. The limited stack, the 8 bit limit, the zero page idiosyncrasies, the
page crossing bugs (some corrected in 65C02), etc.
Z80, while also full of adhoc-isms is a much more pleasant target for a C compiler, only just for its 16 bit register and stack.
There's also sometimes the incentive to slow things down because if it is too fast, the client will perceive that he paid too much money for an operation that takes no time, i.e. it doesn't exists seems unimportant.
One funny anecdote about Zuse during the war was that he managed to save his Z4 because it was named as V4 in the paperwork. The wehrmacht officers thought it was one of these retaliation weapon V1, V2, V3 so V4 was very important and got high priority to be hidden away somewhere.
git checkout master
git pull => fetch and merge the new things on master
git checkout develop => go back to your work branch
git rebase master => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge
do not forget to force push the changes of your branch
git push origin --force develop => to update your branch on the server
Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc.
If git had been released with the same license model of BitKeepr it NEVER would have taken off.
That's similar to what I do on our translation memory at the Commission. The issue we have is that we search for sentences, not words and the medium length of sentences in the database is around 120 characters and we have around 1.5 billion sentences in the database. A pairwise Levenshtein would be completely impossible as added to that we have to take care of replaceables in the segments (dates, numbers, months, weekdays, etc).
To accelerate the search we use fuzzy keys which are trigram counts based and have them organized in a ternary tree. For the fuzzy distance, a simple difference calculation between 2 fuzzy keys is close enough to Levenhstein distance that we don't need more fancy metrics (for short sentences it is relatively bad but short sentences are mostly irrelevant for translation memories). Our fuzzy index reduces our search space for the Levenshtein distance calculation by 4 to 5 order of magnitudes (a sentence search is done on a space of 100K-300K sentences, after filtering the number of candidates rarely go beyond 100).
Yes, that one is especially nasty as &p->bar[0] is a constant expression completely solvable at compile time.
It's equivalent to the offsetof() macro of stddef.h
The fundamental difference is that AMD respects exclusion domains even when speculating a thing intel is notorious for not doing. It's a fundamental difference.
Intel: speculate without checking rights and crush afterward if a violation happened. Gains some points in benchmarks but makes side channel exploits very interesting.
AMD: speculate only on allow if allowed. No need to crush afterward, no speculation violate security. Costs some points in benchmarks but make side channel exploits not very interesting.
Epyc also has hyperthreading. Intel's security woes have more to do with a deep corporate philosophy than anything else. Meltdown happened because Intel works with the premise: you can cheat (not respect protection domains) if nobody sees it, AMD respected the protection domains in its implementation even if not visible.
I know that my assessment is a bit inflammatory but that is what it is.