The Atari 1200XL fiasco
goto10retro.com
goto10retro.com
Re compatibility, I never came across software that didn't run on it. I'd read in magazines that there were issues, but never once experienced it. One interesting software change, though (but true of other XL computers, too) was that the color "artifacting" worked differently on it than it did the 400/800. For example, Ultima III used color artifacting, and so playing it on my system produced some incorrect colors...most notably the sea was red.
I did come across one hardware issue...a cheap third-party parallel interface adapter that didn't work, and that we thought at the time was defective, but I now think it's likely to have been affected by the incorrect power wiring in the 1200XL's SIO adapter. It was cheap enough that we didn't lose too much money on it, and I ended up getting the far superior ICD P:R: Connection instead.
The Atari community was a super great community to be in. And in so many ways, Atari was doing things that wouldn't be seen again for years, if not decades. Atari's SIO port is famously a predecessor/inspiration of USB. The APX Exchange was basically a third-party app store decades before Apple popularized the concept. The machine was hackable and moddable (I bought a 256KB upgrade kit for mine). When I migrated to PC for college use, it hurt to have to fall back to CGA...even EGA was just ugly, compared to what my 1200XL was capable of (although the 80 column displays were nice compared to Atari's 40-column).
I patched my copy of the game and sent the patch to the publisher (Microprose, IIRC) but never heard from them.
They would have done a lot better, even at a higher price, if they had focused on it. The Atari 8-bit line had a lot going for it and was arguably superior (flame wars incoming, Atari army please help me) in many ways than the C64.
It was gone so bad that most Windows developers, me included, advise focusing on Win32/Windows Forms/WPF, at BUILD 2024 WPF got back into the spotlight as official Windows GUI framework (WinUI 3.0 keeps being years away from feature parity with UWP, let alone WPF), even Office and XBox teams rather reach out to React Native than bothering to make XAML C++ in WinUI 3.0 work.
Check the agenda for BUILD 2025, hardly anything related WinUI 3.0 / WinAppSDK.
And if you want to have some fun, come around into the Github discussion issues from all the related repos.
Many have pointed this out but just get shouted down by those haven't had to endure the UI framework pain that the company has put developers through over the past ten to fifteen years. Microsoft officially is completely behind dotnet and is committed to its continued success. Same message they've given for all their UI frameworks. The only difference being dotnet still gets lots of resources but so did all of the frameworks before they were left to rot from resource and leadership starvation.
As such I get what it means to be in a Microsoft shop, in a UNIX shop, in those that don't care, that use a mix of stacks whatver.
The .NET team has made great achievements turning the ship around from Windows only into a cross platform product.
However occasionally when they complain on social media, why despite all this effort, there is still some issues getting .NET adoption over Go, Rust, Java, Python, nodejs, you name it, they should start inside Redmond buildings.
DevDiv nowadays is no long .NET and C++, regardless of .NET came to be, Microsoft has seen it needs to be back into Java game and even has their own OpenJDK distro.
The initial implementation of VSCode support for Go was done by Microsoft, and nowadays they have their own Go distro.
While the .NET team makes great developments to ease cloud native development, the projects Azure works on and contributes to CNCF are a mix of Go and Rust for th most part.
As for the UI side, from what I can tell, been part of the receiving end, most of the key developers are gone, the new blood are all millennials that grew up with macOS, Linux and Chromebooks, naturally no background experience on Windows developer ecosystem, and strong focus on Web development.
Naturally they aren't to blame, they know what they know, what apparently is missing is proper managment, resources and guidance, so that they can deliver to what used to be "Developers, Developers, Developers".
Then in one instant they get a real cross-platform UI framework, with a competent team as a free bonus.
It is actually incredibly compelling, the cross-platform .NET offering.
If you look at all the Go, Python and Rust UI toolkits, none hits the bar. They invariably write their own toy framework with 2 components, or they duct tape a leaking C++ toolkit on top with bad interop.
But maybe it should not surprise me, C/C++ got out of fashion (with good reasons), but the devs lost the UI toolkit with it. The average dev does not command a language with an ecosystem that is up to the task. So it is some slow Python + some crapshoot UI.
Linux finally has an option for good, performant UI, written in a sensible high level language with a vast standard library. Look at HN, people hate the electron stuff. There is just a shortage of competent programmers.
Java + JavaFX might be an other option next to .net core, but Java is verboten as well. People rather fix runtime crashes in the untyped langue they learnt in their first tutorials than broaden their horizon.
The problem is that, to first order, the web is the only thing that exists. To second order, the web and Windows are the only things that exist. So, any GUI toolkit needs to get traction there first--which is exactly what Electron does.
HN readership, of course, don't care about either of those so anything they develop are doomed to fail from the very start.
Bonkers. But for desktop use there are crazy good options these days, unless one cannot part from their tutorial language, which is these days oneOf {python, typescript}.
Citation, please? Really, I'd love to know what those options are.
I know of nothing that works particularly well on desktop on more than one OS.
For all its faults, Electron works pretty much the same everywhere ... Windows, Linux, and macOS.
For .net you have Avalonia that is also cross-platform.
[0]: For example https://github.com/dotnet/runtime/issues/114024
Where I think the 64 had the edge was in the incredible SID chip and I'd argue the amazing hacks that were found for the system over the years that enhanced what the 64 was capable of.
The SIO of the Atari is also another standout design, which flies under the radar. It enabled a much cheaper diskette drive than the C64. The designer of the SIO, Joe Decuir went on to make USB and credits his work on SIO as the basis of USB[0].
Even the use of letters for devices was already ahead of DOS with D: being for diskette, but that was shorthand for D1:, with D2: being another and any other letter could be an installable device with numbered instances. Keyboard/screen I/O was addressable as E:.
I don't think any of this is denied by C64 fans.
The C64 on the other hand could push nearly 6x the sprite data per line, had Color RAM for more interesting tile work, the SID was more capable for music, and it had much much better support for high resolution graphics.
For their time they were very comparable but when (ab)used just right the C64 can do a neat NES impression. The Atari can't do that, but it can do some bonkers 3D using the super low resolution modes.
The PAL C64 was actually slightly under 1Mhz but you had a lot more VBlank time to do stuff.
The lower resolution also means less time plotting pixels so for any sort of software rendered effect the Atari machines are miles ahead.
You're right about the bonkers 3D! https://www.youtube.com/watch?v=qwcN9FraNjQ https://www.youtube.com/watch?v=KatdrdEVEwY&t=532s
I think the main thing was that Atari (pre83 company) abandoned the 8 bit line too early, and didn't make the 5200 cross-compatible.
One problem is that these kinds of architectures that relied on special custom chips have inevitable obsolescence built in. When your "API" for graphics programming is a custom chipset at a certain clock rate with certain capabilities, it's just not going to scale up past a certain point. You get initial superpowers, but then Moore's law just makes it pointless.
See also: Amiga.
I agree that the custom chips were a dead end. However the ST line could have beat the mac if management was any good. (as could/should the Amiga, though I was Atari locked at the time and so I didn't pay attention to what they were doing)
But I also think there's just no way Atari Corp could have taken on e.g. Apple regardless of management. They simply didn't have the capital, market penetration, etc. to carve out a segment that big. Apple was already a big deal and although the Macintosh was not really a big success at that point, there was a giant company behind it with top tier talent, and lots of cash.
And it seems those are Polish guys (https://www.atari.org.pl/forum/viewtopic.php?id=4520)
-- EDIT --
I found it: only version for Atari 130XE (i.e. 128KB RAM - this is not the standard, I guess it could run with cartdrige on 65 XL/XE maybe?), year 2006/2007 (fresh :) )
We can say that now, but it's worth remembering the Atari 8 bit computers came out over two years before the C64. Not such a big gap in computing today, but back then it was a lot.
ex-Atari people talking about what they could have done better is always an interesting youtube phenomenon. (as with, for example, ex-Sun people, you hear a lot of theories but you never encounter anyone who says "yeah, I was the guy who made the whole thing fail")
As someone super into retro computing now, who also lived through the history getting my first computer in 1981, participating in users groups, reading all the zines, going to regional and national trade shows for 8-bit home computers, etc, this was (and still is) a significant recurring theme. Owners of 8-bit and 16-bit computers in the 80s/early 90s (and retro hobbyists/collectors today) obsess about the mistakes made by their respective manufacturers. Often this armchair analysis results in frustrated conclusions like "If only (Atari/Commodore/Tandy) had done X" the computer would have "made it" (ie survived against the PC). I engaged in this prevalent pastime myself for years and even today there are forums full of questions seeking to post mortem the "the fatal mistake(s)".
The fascinating part for me is that my early hobby computing led to programming, product-making and tech startup entrepreneurship. By the mid and late 90s I'd evolved from sneaking into Comdex and CES circa 1983 to now launching products in my startup's huge Comdex booth literally next to Microsoft's, with our own private hospitality suites and VIP parties. I'd somehow gone from fanboy to insider. During this era I had multiple private business meetings with industry luminaries I'd idolized including Bill Gates, Steve Jobs, Andy Grove and many others. I'd even met, had a meal with or otherwise gotten to personally know 8-bit era luminaries including Nolan Bushnell, Jay Miner (designer of the Amiga), a couple of Tramiels and so many others. I got to ask my fanboy era questions directly to the players - and the best part was that I was then a peer and the meetings were private. I got a lot more color and perspective than the answers they gave to the press or even at retro-computing conference panels. It was fascinating! But overall I also learned that, aside from a couple notable exceptions, there was no single "Big Mistake". The reality was far more complicated and kind of boring: there were complex business, financial, manufacturing and distribution challenges far beyond users group hobby analysis. The future was unknowable and they were living through the first iteration of what only later became obvious patterns - and they were just doing the best they could to figure it out enough to survive.
By the late 2000s I'd graduated to selling my third startup to a Fortune 500 valley tech giant and became a senior exec driving strategy and identifying new opportunities and markets, as well as leading large teams of MBAs, bankers and lawyers to identify, analyze and negotiate multi-billion dollar acquisitions of other tech companies. And this perspective is the one that most informed my prior obsession with identifying "the fatal mistake" which doomed Atari, Commodore, Tandy, Sinclair and so many others. Having recently retired early, just for fun I've delved into the history and using my post-2000s expertise done rigorous strategic analyses.
In every case the answer is the same and, frankly, a little disappointing: Nothing they could have done would have "saved" them for more than a couple years. While Atari, Commodore, Tandy et al did make many mistakes, none of them were the root cause of their eventual demise. Even if those mistakes had been avoided, it would only have delayed the inevitable. In each case, macro factors beyond their control that were baked into the market, the technology or their own DNA, doomed them. For example, one of the Amiga's greatest advantages in 1985 was the brilliant custom chipset designed to exploit every quirk of analog video timing. And by the early 90s that great advantage was one of its biggest weaknesses. Also, the much-beloved 68000 series processors at the heart of the Amiga and Atari ST were ultimately doomed by the combination of being made by Motorola and being, perhaps, the ultimate expression of CISC architecture (which made them fun to program by hand in assembly language). But RISC was ultimately the only way forward when Moore's Law scaling kept delivering ever more gates into the 90s. But bridging over from CISC to a RISC ISA while maintaining backward compatibility was enormously complex. Only Intel eventually managed it and very nearly died in the attempt. Intel's lead in process fabrication helped them over the hump but Motorola was too far behind in fab tech because they hadn't invested as deeply. For Intel it their lifeblood and, ultimately, existential. For Motorola's board of directors, CPUs were just another business in their portfolio of businesses. Motorola was a decades old conglomerate that made prudent financial calculations. Intel was born as a chip startup and would either live or die as one. Andy Grove had to bet the company and find a way to make it work. Motorola didn't.
The Apple II was a contemporary, in fact a predecessor of all these systems. So, what did they do right, or what went right for them, that enabled them to make it? I suspect it was the penetration of the Apple II into education and business that helped make it possible, but suppose Steve Jobs had been in charge at Commodore or Atari?
Apple is indeed an extraordinary outlier (as is Jobs). If you look into the history of Apple's Gil Amelio days, very near-death and Steve's return, it was IMHO, a remarkable example of a series of fortunate miracles coinciding to allow Steve to brilliantly save the company when it had been only weeks away from death. Jobs calling Bill Gates and convincing him to quickly loan $400M to Apple averted disaster potentially by a matter of days. And Gates only did that because MSFT was being sued for anti-trust by the Justice Dept and needed Apple to survive as an example that Wintel still had some competition. Apple's survival in that period is the closest close thing I think the industry has ever seen.
To answer your last question, Jobs was undoubtedly incredibly brilliant but it took every ounce of that brilliance AND some crazy good luck for Apple to survive. Ultimately, it was Jobs plus flukes, so no, just Jobs without the flukes wouldn't have changed anything at Atari or Commodore. Even on its death bed Apple had a much better brand, distribution, market potential and talent than Atari or Commodore ever did. Plus Steve had his hand-picked entrepreneurial team from Next with him. The situations at Atari and Commodore were just much weaker in every way, so I don't think any single super hero, no matter how super, could have saved them.
I don't know how much it moved the needle but it was astonishing how much schools and home users - parents whose kids used the machines at school - were willing to pay for an Apple II well after it was a technically obsolete machine. It definitely helped them to some extent.
(don't get me wrong, I love those machines in my bones, but they were pretty overpriced after a while)
Fast forward a few years, and the Apple II was still very usable and competitive, with RAM expansion options up to 128k, higher res graphics, and 80 column text, while still supporting the same software.
One other thing is that the Apple II was wildly profitable. It had no custom chips, just cleverly used commodity chips and some ROMs. This includes the fast and cheap disk system.
Desktop publishing.
The Macintosh/LaserWriter cash cow absolutely dominated desktop publishing for a very, very, very long time.
This gave Apple access to enterprise accounts that other computer companies did not have.
I certainly didn't appreciate the impact of CISC vs RISC architecture at the time. I understood the conceptual difference between them at a high level but didn't get why that caused Motorola to decide they couldn't keep scaling beyond the 68060. As a user and fan of 68030 and 040, I just didn't understand why they'd walk away from, arguably, the second most popular flagship computer ISA at the time. And they actually told computer manufacturers that the 68060 would be the end of the 68K line more than a year before 68060 even shipped. I was like, WTF? They weren't even done with the latest, greatest chip when they decided to kill the whole line, orphaning all that fantastic software from ever having any upgrade path to the future.
Only later did I gain a deeper appreciation for the impact. A few key things informed me:
* My high level understanding of CISC vs RISC wasn't complete back then. In the late 80s there was a lot of debate among CPU ISA designers on the relative merits between CISC and RISC - and that even extended to the definitions of the terms (which were fuzzy). A good example is this legendary Comp.Sci Usenet discusson: https://yarchive.net/comp/risc_definition.html. Only when I dove into those debates in the last 10 years did I really start to get the larger picture.
* The part that mattered most between RISC/CISC wasn't that RISC had less instructions than CISC (although it usually did), it was that those instructions were much less complex AND that the addressing modes were much less complex. This meant that, in general, RISC ISAs were easier to decode because instruction and operand length tended to be more fixed. This also had a bunch of other downstream effects generally causing RISC-ish ISAs to be easier to pipeline more deeply, easier to branch predict, easier to speculatively execute, etc. These are all things that enable putting extra gates to work speeding up execution.
* I was a huge fan of the 68K's insanely powerful addressing modes which let savvy assembly language programmers pack huge functionality into fewer instructions with addressing modes like indirection on both the input and output along with setting a bunch of flags and pre/post operations like decrement/increment. Programmers not only called 68K addressing modes powerful but also things like "orthogonal" and even "elegant." But all those varying instruction lengths with up to 14 different addressing modes plus even more optional flags modifying behavior before and/or after also created a complexity explosion for CPU architects trying to implement the most powerful new optimizations. That's one big reason why the 68060 was over a year late coming to market. It was only dual pipeline but even doing that was triggering unexpected avalanches of design complexity.
* Both Intel and Motorola realized the only way to continue increasing performance in the future while maintaining software compatibility with their old CISC ISA was to (basically) make future processors RISC CPUs running an extra hardware layer emulating a CISC ISA. It was both hard and costly in terms of gates and performance. Intel's lead in fab process helped them hide that performance cost and keep showing generational net speed increases as they navigated the transition. Motorola realized they'd probably have a generation or two of CPUs that weren't meaningfully faster until they bridged the gap and were on the other side.
There's a lot more but I'm certainly not a domain expert in CPU design and already summarizing my non-expert understanding of expert debates, so I'll leave it there. But it's pretty fascinating stuff. Both Intel and Moto realized that pure RISC implementations would probably beat them soon. Each company responded differently. Intel made the RISC-emulating-CISC approach to ISA compatibility (broadly speaking) work well enough to survive the transition. Motorola decided it was too risky (probably correctly given their fab technology and corporate resources), and instead chose to break with the past and partner with IBM in moving to Power PC. For Atari, Commodore, Apple et al this was a planetary level asteroid impact. If developers and customers lose all software compatibility with your new products, that makes the choice of moving to your next generation not much different than moving to another platform entirely. Only Apple managed to survive (and even they almost didn't). Arguably, they only treaded water with great design and marketing until saved by the iPod.
I should also mention there was another huge asteroid for vertically integrated non-Wintel computer platforms right behind the CISC/RISC asteroid. In the early to mid 90s Moore's Law scaling was allowing desktop computers to improve rapidly by growing dramatically more complex. It was getting to be more than one company could do to win on each separate front. On the Wintel side, the market solved this complexity by dividing the problem among different ecosystems of companies. One ecosystem would compete to make the CPU and chipset (Intel, NEC, Cyrix, AMD), another would make the OS (Windows/OS/2), another ecosystem would compete to make the best graphics and yet another would compete on sound (Creative, Yamaha, Ensoniq, etc). It would require a truly extraordinary company to compete effectively against all that with a custom vertically integrated computer. There was no way a Commodore or Atari could survive that onslaught. The game changed from company vs company to ecosystem vs ecosystem. And that next asteroid even wiped out stronger, better-capitalized companies that were on pure RISC architectures (Sun, SGI, Apollo, etc).
You certainly see the impact of the "don't add too many instructions/flags" style of design even today in things like RISC-V that doesn't even use condition codes (an unexpected source of complexity in ISA spec, since every instruction must define exactly how it affects or does not affect each of several condition codes - RISC-V has none of that), expects you to use instruction fusion in larger implementations and defines "compressed" instructions as a mere shorthand for existing full-length instructions in order to simplify decode. ARM64 has made different choices on all of these things, it will be quite interesting to see how they compare in real-world scenarios at the higher end of performance.)
However, Tandy was the only one that could have survived as they had PC compatibles that were actually better than the original PC computers. Unfortunately, I seem to remember that Tandy had a big accounting/embezzlement thing back about the time that they needed to be hyperfocused on the PC business.
If you're interested, this retro site has several articles covering the Tandy PC clones, why they struggled at launch (weren't actually very compatible early on) and how they eventually failed (weren't differentiated or cheaper at the end). https://dfarq.homeip.net/tandy-1000-models/ But Tandy's PC-compatibles sold very well in-between the first and last couple years. More interesting from a retro perspective though, a lot of people don't realize just how dominant Tandy/Radio Shack's unique (non-PC) computers were between 1977 and 1985. They outsold even Apple, Atari and the C64 in many of those years.
Tandy just used the Motorola reference design so there was nothing unique or proprietary to Tandy. The graphics were just a straight bitmap from CPU RAM, no sprites, tiles, or selectable palette colors. The sound output was a plain six bit DAC that had to be driven by the CPU on interrupts.
8080, 8085, Z80, 6803, 6809, 68000, 8088, V20, 80186 (of all things!), and also the purely PC-compatible stuff.
[0] https://en.wikipedia.org/wiki/List_of_TRS-80_and_Tandy-brand...
So while 8 bit would have been swept no matter what, the 16 bit ecosystem would have had another outcome.
I agree that the issues w/ m68k-series processors were an underappreciated factor behind the demise of the Amiga and Atari ST computers. The Macintosh line managed to transition to PowerPC, but they did so via software emulation. That would've been highly problematic for the kind of software (games and early multimedia - not DTP, which was the Macintosh domain) where the Amiga and Atari ST were at their strongest. Other m68k machines in common use included, e.g. Sun and NeXT workstations which would've been running highly portable code without 'tight' performance requirements.
This is an excellent point and one I hadn't fully appreciated until reading your comment. Most of the popular 68K software on Macs (such as DTP) was more amenable, or at least tolerant, of running under emulation. Even the popular games on Mac like Myst weren't as real-time critical as popular Amiga and Atari ST games which tended more toward arcade style and sometimes even accurate arcade ports. While I'm sure there were arcade style games for color 68K Macs, they weren't the majority. Also, because the Mac didn't have so many tightly integrated custom co-processors, my sense is that Mac 68K software wasn't as tightly hardware coupled and counting on specific timing interactions. A fair amount of Amiga software would read and write directly to hardware registers instead of using OS calls and even if it only used OS routines, it could still be highly dependent on precise behavior. Once again, we see that aspects which had made the Amiga and Atari ST great in the 80s, made it harder to navigate the transitions necessary to survive the 90s.
It would be interesting to have modern emulator authors compare notes about the software libraries between these platforms. While I'm sure Mac emulator authors still found a lot of 'misbehaving' Mac apps to deal with, my sense is the Amiga software library was bonkers to support in emulation. The WinUAE Amiga emulator has long had a precisely cycle-accurate mode which is less performant but simply necessary in many cases. And as mature as WinUAE is, the team is still discovering edge cases where 40 year-old games and graphics apps have never been emulated correctly.
Conversely, I remember around 1992 I bought a Macintosh emulator for my 68020 Amiga and it performed quite well. I used it for work to run Mac DTP applications. The emulator ran in software but used a small hardware dongle on the Amiga's parallel port to import original Mac ROMs which you needed to buy separately. Of course, both the emulation source and target were 68K-based but it indicates that most Mac software was reasonably well-behaved in terms of hardware dependence. If a little Amiga startup was able to write a pretty good Mac emulator, it was certainly possible for Apple themselves to it better as few years later with a much faster PowerPC CPU.
Finally, it's clear that post 1990 both Atari and Commodore were in increasingly weaker positions, not only financially but in terms of staff depth. While both still had some remarkably talented engineers, the bench wasn't deep. I know that at least at Commodore, toward the end they'd canceled their much improved, new Amiga chipset project (AAA). Even though it was almost complete with (mostly) working test silicon on prototype boards, they canceled it because it had become obvious future Pentium and RISC CPUs would outperform even the 68060 and AAA custom chips. At the time Commodore folded engineering was working on the 'Hombre', an entirely new design which would have been based on an HP RISC CPU. For graphics the main thrust would have been new retargetable graphics modes for hi-res, high-frequency monitors (1280 x 1024). https://en.wikipedia.org/wiki/Amiga_Hombre_chipset
The plan was to support legacy Amiga software with a 68K emulator on the RISC CPU driving a new chip created specifically to support legacy Amiga graphics modes. When I later read this, I remember being quite skeptical that hybrid software/hardware emulation would have worked very well for the eclectic Amiga library of legacy software. As much as I loved the Amiga, the OS stack could then only be described as 'crufty'. It had been upgraded a little over the years but still contained major legacy components from different eras and many of the people involved were no longer at Commodore. Given that reality, the plan had been to base the new Amiga on Windows NT.
But - even if Commodore somehow overcame the myriad technical challenges, lack of resources and depleted talent bench, once a next-gen Amiga isn't based on the 68K, AmigaOS or the custom chips and boots Windows NT in XGA mode - is it still really an Amiga? Certainly, at least some of my software wouldn't have worked anymore so, facing the decision to buy a new, quite different computer, why wouldn't users also look at the, probably, cheaper Packard Bell Pentium running Windows 95 down at Costco? After all, with the Pentium and Windows 95, the PC juggernaut had finally coalesced into a coherent whole that could be compelling to both home users and graphics, gaming, multimedia obsessed hobbyists. And new Doom/Quake quality games were coming out almost weekly. That's when even I bought a PC and started using it as my main daily driver. Of course, I kept my awesome, fully loaded, tweaked out, much beloved Amiga system on the desk alongside it for a couple years. But web pages never quite looked right on the Amiga and sharing files on the network was hardly seamless. Sadly, it was increasingly clear the world had moved on. In many ways the Amiga (and other notable platforms of the 80s) had blazed the trail showing the way to the future - but it was a future they would not be a part of.
Because that was usually a business decision and not a technical one.
Commodore machines came with a rather hefty serial bound book that introduced you to programming and gave you a memory map of the hardware, important PEEKs and POKEs.
Atari's came with trade secrets.
(I remember reading it end to end as a child laid on my parents' bed because the light was better in there than in my room, shortly followed by developing the programming addiction that has stuck with me the rest of my life ;)
It didn't cover arm2 assembly, but my parents bought me an extremely good book that did - and described the chip architecture itself in detail as well.
I only touched a Commodore at a friend's place to play games on it, but it sounds like they also understood hobbyists :D
But starting with De Re Atari by Chris Crawford in 1982, a lot of development material became available. Compute! had a great line of books, including Mapping the Atari.
It was shame it took so long for that material to appear because the Atari 8-bit have a rather elegant OS, especially compared to its contemporaries.
That was true in the early days of the 400/800, but by 1982 when the 1200XL was released (a few months ahead of the C64) they'd corrected themselves. The board schematics and assembly source for the ROM was a book you could buy at the dealer, and sources like De Re Atari and Compute Magazine had collated all the relevant details of the handful of ASICs such that people could start playing weird tricks.
It wasn't Woz's Red Book (neither was Commodores documentation), but it told essentially the whole story of the devices down to the MMIO level.
Problem is, there were always programs that abused the OS so much that it would have been impractical to accommodate them, since bundling extra ROMs is costly. The worst case I know of is a program that used an entire section of the OS ROM as an XOR encryption key for sectors on disk.
As for Atari vs. C64, I love the Atari but it needed an update to the custom chips to compete with the C64 and other newer systems. But instead, Atari was looking at adding a 300 baud modem and a speech synthesizer to the computer instead.
That wasn’t as big a deal in the 80s as it is now. Reputation was limited to real life friends and maybe a few homegrown newsletters or computer clubs.
Very few people were using the Internet to share opinions in the early 1980s, so “reputation“ could be very effectively managed by Atari and other companies through advertising and leaning on trade media to suppress negative reviews and angry letters to the editor.
That is, unless the problems were too big to ignore and customer anger became too great, as was the case with many late era Atari 2600 games.
A bigger issue for the 1200XL was price as well as something not addressed in the article: competition. By this point there were other platforms to consider, often at better price points with attractive features and software.
It was a big deal for me. Software expenses were a huge portion of the cost of owning a computer.
Almost always the price of the computer was less than the cost of buying software to run on the thing.
Letter Perfect was around $300. If it didn't run on the 1200XL I'm not shelling out $800 for the computer and another $300 for a compatible word processor.
I am convinced that cross-vendor incompatibility was THE reason for CP/M's failure. Not anti-competitive behavior, not shenanigans, but the fact that if you spent $495 on the Kaypro version of Wordstar and then bought an Osborne, it wouldn't work. Same Z80, same CP/M, wouldn't work.
Even today PC manufacturers are only starting to remove the BIOS compatibility layers that allow you to boot >30-year-old versions of DOS on a modern hardware, and Apple has provided binary translators since the 1994 PowerPC transition and supported them for years after breaking native compatibility.
But CP/M had a well defined API. Compliant programs would work on different vendor's computer, much like in the MS-DOS domain. The key difference was, that CP/M had no well-defined disk format, i.e. you couldn't just swap disks (for evaluation purpose only, of course) with your buddy if he didn't happen to own the same type of computer; you had first to transfer the software via other means, e.g. serial interface (perhaps using kermit). A bridge too far for most casual computer users.
I never found out why they copied the design of a completely different machine. I guess they just liked it.
For those reading: https://en.wikipedia.org/wiki/TK_2000
Huge expense to make those.
So we would just type programs in from magazines and the worst part about it was that sometimes we wouldn’t finish and then his parents would shut the computer off at night and we’d have to start over.