6 ms·

Microsoft was one of the first companies who fully internalized the importance of seamless backwards compatibility. The lessons had been around for a while, suc

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.

userbinator 2y ago
MS has unfortunately now fallen greatly from that, and gotten onto the same aggressive and hostile trendchasing practices as the rest of Big Tech. Only their legacy keeps them from totally losing the market at this point.
- pjmlp 2y ago
  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 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.
  - Mountain_Skies 2y ago
    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 dotnet. No one wants the shitshow that has been Microsoft's desktop UI over the past decade to spread into the rest of the dotnet ecosystem but most are wary of it happening. Anders was the very last person in the company who should have been the face of the Typescript compiler project using Go. 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.
    - pjmlp 2y ago
      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".
      - exceptione 2y ago
        The smartest thing Microsoft could do, imho, is cancel all their billion UI variants, bless Avalonia and throw all the saved millions of dollars to them. 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.
        mixmastamyk 2y ago
        Linux distros are rewriting their installers and partition tools in web technologies these days. Hard to believe but the direction is clear, no one cares about local UI toolkits.
  - neonsunset 2y ago
    FWIW WinRT / WinUI 3 was ported onto NativeAOT (9). There is are greater ongoing efforts[0] to make the two play nice together from the people working in Windows. But I think it's just efforts from specific individuals who care and the outcome solely relies on their motivation and continued employment, and is not facilitated by the org or its culture in any way, if anything, it happens despite it. [0]: For example https://github.com/dotnet/runtime/issues/114024 https://github.com/dotnet/runtime/issues/114024
    - pjmlp 2y ago
      Yes, those individuals have been great contributors and kudos to them, but it is visible, specially from the last community call how things have been going.
eddie_catflap 2y ago
I love the C64 but the Atari 8-bit line was fine indeed (one of my first exposures to home computing was Star Raiders at a family friends house - blew me away). Archer Maclean, author of Dropzone (and other titles) famously labelled them the 'Porsche of home computers'. 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. https://en.wikipedia.org/wiki/Dropzone#Development https://en.wikipedia.org/wiki/Dropzone#Development
rbanffy 2y ago
The big pro of the Ataris was their graphics. Replacing a frame buffer with a display list and a dedicated processor that keeps banging out pixels based on its "program" is brilliant. It's an interesting maximalist counterpoint to the Apple II's minimalist approach to color graphics.
- pavlov 2y ago
  It’s a bit like an early GPU.
  - rbanffy 2y ago
    Very much. It was a direct ancestor of the Amiga graphics architecture, and certainly inspired many other less known architectures.
- karmakaze 2y ago
  The C64 definitely had better sprites and music, no contest. But there's a certain elegance to the way the Atari did their graphics in particular. It was so much more with simple building blocks where you could immediately see the power of it and take a long time extracting value from it. 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:. [0] https://en.wikipedia.org/wiki/Atari_SIO https://en.wikipedia.org/wiki/Atari_SIO
ndrake 2y ago
Atari 800 XL <3
- atari800xl 2y ago
  Thank you. I love you too.
sirwhinesalot 2y ago
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 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.
- curiousObject 2y ago
  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.
  - RiverCrochet 2y ago
    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.
    - bluGill 2y ago
      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)
      - pezezin 2y ago
        The colorburst signal? https://en.wikipedia.org/wiki/Colorburst https://en.wikipedia.org/wiki/Colorburst
JKCalhoun 2y ago
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.
- mst 2y ago
  My first Archimedes came with a ring bound user's manual that was, IIRC, about 1/3 a guide to using the Risc OS GUI, and then 2/3 a programming guide to the version of BBC BASIC that shipped with it. (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
- plefebvre 2y ago
  True, the Atari 8-bits did not come with developer docs and in the early years little information was available. This certainly hurt its initial adoption. 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.
- ajross 2y ago
  > 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.
ack_complete 2y ago
I would say Apple had been doing a fair amount of it prior to Microsoft, if you looked at the way they carefully patched the Monitor II ROM in later models. This is something that Atari didn't get at first when they first revised the OS in the 1200XL and shifted entire sections of code, before reverting major sections back to match the original OS. 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.

userbinator 2y ago

MS has unfortunately now fallen greatly from that, and gotten onto the same aggressive and hostile trendchasing practices as the rest of Big Tech. Only their legacy keeps them from totally losing the market at this point.

pjmlp 2y ago
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 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.
- Mountain_Skies 2y ago
  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 dotnet. No one wants the shitshow that has been Microsoft's desktop UI over the past decade to spread into the rest of the dotnet ecosystem but most are wary of it happening. Anders was the very last person in the company who should have been the face of the Typescript compiler project using Go. 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.
  - pjmlp 2y ago
    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".
    - exceptione 2y ago
      The smartest thing Microsoft could do, imho, is cancel all their billion UI variants, bless Avalonia and throw all the saved millions of dollars to them. 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.
      - mixmastamyk 2y ago
        Linux distros are rewriting their installers and partition tools in web technologies these days. Hard to believe but the direction is clear, no one cares about local UI toolkits.
- neonsunset 2y ago
  FWIW WinRT / WinUI 3 was ported onto NativeAOT (9). There is are greater ongoing efforts[0] to make the two play nice together from the people working in Windows. But I think it's just efforts from specific individuals who care and the outcome solely relies on their motivation and continued employment, and is not facilitated by the org or its culture in any way, if anything, it happens despite it. [0]: For example https://github.com/dotnet/runtime/issues/114024 https://github.com/dotnet/runtime/issues/114024
  - pjmlp 2y ago
    Yes, those individuals have been great contributors and kudos to them, but it is visible, specially from the last community call how things have been going.

eddie_catflap 2y ago

I love the C64 but the Atari 8-bit line was fine indeed (one of my first exposures to home computing was Star Raiders at a family friends house - blew me away). Archer Maclean, author of Dropzone (and other titles) famously labelled them the 'Porsche of home computers'. 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. https://en.wikipedia.org/wiki/Dropzone#Development https://en.wikipedia.org/wiki/Dropzone#Development

rbanffy 2y ago

The big pro of the Ataris was their graphics. Replacing a frame buffer with a display list and a dedicated processor that keeps banging out pixels based on its "program" is brilliant. It's an interesting maximalist counterpoint to the Apple II's minimalist approach to color graphics.

pavlov 2y ago
It’s a bit like an early GPU.
- rbanffy 2y ago
  Very much. It was a direct ancestor of the Amiga graphics architecture, and certainly inspired many other less known architectures.
karmakaze 2y ago
The C64 definitely had better sprites and music, no contest. But there's a certain elegance to the way the Atari did their graphics in particular. It was so much more with simple building blocks where you could immediately see the power of it and take a long time extracting value from it. 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:. [0] https://en.wikipedia.org/wiki/Atari_SIO https://en.wikipedia.org/wiki/Atari_SIO

ndrake 2y ago

Atari 800 XL <3

atari800xl 2y ago
Thank you. I love you too.

sirwhinesalot 2y ago

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

curiousObject 2y ago
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.
- RiverCrochet 2y ago
  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.
  - bluGill 2y ago
    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)
    - pezezin 2y ago
      The colorburst signal? https://en.wikipedia.org/wiki/Colorburst https://en.wikipedia.org/wiki/Colorburst

JKCalhoun 2y ago

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.

mst 2y ago
My first Archimedes came with a ring bound user's manual that was, IIRC, about 1/3 a guide to using the Risc OS GUI, and then 2/3 a programming guide to the version of BBC BASIC that shipped with it. (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
plefebvre 2y ago
True, the Atari 8-bits did not come with developer docs and in the early years little information was available. This certainly hurt its initial adoption. 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.
ajross 2y ago
> 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.

ack_complete 2y ago

I would say Apple had been doing a fair amount of it prior to Microsoft, if you looked at the way they carefully patched the Monitor II ROM in later models. This is something that Atari didn't get at first when they first revised the OS in the 1200XL and shifted entire sections of code, before reverting major sections back to match the original OS. 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.