Live data from Hacker News

The Atari 1200XL fiasco

goto10retro.com

21–30 of 88 posts

Re: The Atari 1200XL fiasco

#21
Reports of other software incompatibilities due to the ROM changes would start to come out once the 1200XL was actually released and got into user’s hands, hurting its reputation.

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.

Re: The Atari 1200XL fiasco

#22
post #2

Microsoft was one of the first companies who fully internalized the importance of seamless backwards compatibility. The lessons had been around for a while, such as the fate of the 1200XL. 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.

I was able to get an Atari 400 (not XL, sadly) for a firesale price. The problem with all the Atari's in my mind was that they were not dev-friendly machines. 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.

> The problem with all the Atari's in my mind was that they were not dev-friendly machines.

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.

Re: The Atari 1200XL fiasco

#23
post #2

Microsoft was one of the first companies who fully internalized the importance of seamless backwards compatibility. The lessons had been around for a while, such as the fate of the 1200XL. 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.

I was able to get an Atari 400 (not XL, sadly) for a firesale price. The problem with all the Atari's in my mind was that they were not dev-friendly machines. 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.

Only a few friends had Atari computers when I was a kid. The one thing that stuck out to me was it had a Help key but most programs told you to press 'H' or some other key for help instead of the Help key, which makes me wonder if knowledge of how to detect that key wasn't in the manual? Atari owners were passionate about their computers and seemed happy with them but at least in my little town, there just weren't very many of them.

Re: The Atari 1200XL fiasco

#24

Earlier quoted context omitted.

The Atari line was much better at scrolling, had a much much better master palette, supported display lists (nicer than setting up interrupts in the C64) and the POKEY had some advantages over the SID, not just the extra channel but also in doing beefy sound effects. 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 interes…

The 6502-based Atari computers had the CPU clock held at 80% higher than the C64. That must have been a very significant impact at a time when the CPU had to do most of the work.

It was. Wasn't the Atari's CPU 1.79MHz (3.58Mhz NTSC clock/3)? The NTSC C64 was close to 1Mhz. But it's worse: The C64's CPU was also slowed down by the VIC-II every 8 scan lines to fetch video data, and slowed down additionally if sprites were enabled.

The PAL C64 was actually slightly under 1Mhz but you had a lot more VBlank time to do stuff.

Re: The Atari 1200XL fiasco

#25
post #2

Microsoft was one of the first companies who fully internalized the importance of seamless backwards compatibility. The lessons had been around for a while, such as the fate of the 1200XL. 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.

I was able to get an Atari 400 (not XL, sadly) for a firesale price. The problem with all the Atari's in my mind was that they were not dev-friendly machines. 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.

[deleted]

Re: The Atari 1200XL fiasco

#26
post #8

Earlier quoted context omitted.

As someone that bought into WinRT, saw it as .NET 1.0 done right, and went through all the technology reboots between Windows 8 and WinUI 3.0/WinAppSDK, I can only double down on that remark. 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 fea…

It doesn't seem like Microsoft and Anders Hejlsberg understand what they did when they picked Go over any dotnet language for the Typescript compiler. Anders and his fans insist it was merely picking the right tool for the job but when even the father of C# prefers using Go, combined with Microsoft's tendency to get old technology rot instead of officially cancelling, it sends a very bad message about the future of d…

Indeed, it is one of my favourite ecosystems, however I have always been a generalist, I can't get stuck into being a XYZ Developer for too long.

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".

Re: The Atari 1200XL fiasco

#27

Earlier quoted context omitted.

Actually, it can do a fair impression as well: Crownland has transparent parallax https://www.youtube.com/watch?v=dN5fSp0XGzI 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.

I dunno, Tramiel's Atari Corp kept the 8-bit line going for years after the changeover, adding new models. And they even had relative success later in places like Poland. 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…

Tramiel arguably mismanaged Atari worse than Warner brothers. Sure Tramiel cared about computers, but his management style was hostile to getting anything done.

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)

Re: The Atari 1200XL fiasco

#28

Earlier quoted context omitted.

The 6502-based Atari computers had the CPU clock held at 80% higher than the C64. That must have been a very significant impact at a time when the CPU had to do most of the work.

It was. Wasn't the Atari's CPU 1.79MHz (3.58Mhz NTSC clock/3)? The NTSC C64 was close to 1Mhz. But it's worse: The C64's CPU was also slowed down by the VIC-II every 8 scan lines to fetch video data, and slowed down additionally if sprites were enabled. The PAL C64 was actually slightly under 1Mhz but you had a lot more VBlank time to do stuff.

Atari's CPU was slower in PAL countries, but I don't recall what the speed was. (speed based on something in PAL like the NTSC color clock, but I don't recall what it was called)

Re: The Atari 1200XL fiasco

#29

Earlier quoted context omitted.

Actually, it can do a fair impression as well: Crownland has transparent parallax https://www.youtube.com/watch?v=dN5fSp0XGzI 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.

Oh yeah, for sure. Atari was horrifically mismanaged.

It's not like Commodore was managed much better, in the end.

Re: The Atari 1200XL fiasco

#30
post #2

Microsoft was one of the first companies who fully internalized the importance of seamless backwards compatibility. The lessons had been around for a while, such as the fate of the 1200XL. 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.

The Atari line was much better at scrolling, had a much much better master palette, supported display lists (nicer than setting up interrupts in the C64) and the POKEY had some advantages over the SID, not just the extra channel but also in doing beefy sound effects. 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 interes…

> For their time they were very comparable

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")

Post reply on HN