7 ms·

Not new at all. Remember that Commodore disk drives had their own 6502s in them, for example (some of the big PET drives had two). A joke at CBM was that the 15

Not new at all. Remember that Commodore disk drives had their own 6502s in them, for example (some of the big PET drives had two). A joke at CBM was that the 1541 was the best computer they ever made.

segfaultbuserr 8y ago
Ironically, in the early 80s, we did it mainly because of the shortage of computing power, so we needed lots of co-processors. And now we are still doing it, but mainly due to our excessive computing power. Want to blink an LED? Let's put Linux, Apache and Ethernet in the circuit. ;-) Well, on the other hand, it's unfair to say it's an abuse of computing power, since if you do have the power, making autonomous devices does make a system much more elegant and manageable, and not even talking about the advantages of general processor over specialized chips. Take another look, it also tells us something about early home computer designs - the actual CPUs were usually irrelevant, there were no technical difficulties on the CPUs themselves and you could easily put TWO CPUs in a hard drive. And unlike modern computers, it was not even the most expensive part and the choice was limited, a cheap "trainer" computer with only hexadecimal keyboard, and an expensive home computer with a color CRT often shared a single CPU. The vast majority of the cost and troubles was system design, or putting these parts into a usable computer, with your own solution of input, storage, interface, graphics, software, or a chassis. The standardized IBM PC hasn't came yet, and one needed to create a solution of every subsystem. Every computer was a unique design, often with custom-made ASIC chips for peripherals.
- pjmlp 8y ago
  To be fair something like an ESP32 runs circles around the PCW1512, which we had on the school computer club, where we spent countless hours playing Defender of the Crown. So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices. Naturally it depends on the use case.
  - segfaultbuserr 8y ago
    > So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices. Good point. > something like an ESP32 runs circles around the PCW1512, which we had on the school computer club I think as long as people are having fun with them, the hardware already served a good purpose. Even if the LED blinking is implemented by running Linux. But in my opinion, people who are interested in these popular embedded boards should also learn about the basis of electronics, or just be aware of its existence, and understand the things one could do without buying a premade "board", and that it's possible to blink an LED with a few transistors. Well, I think most will find out by themselves, it's just a matter of time and guidance.
    - AnIdiotOnTheNet 8y ago
      My problem with using things like the RPi for such simple LED blinking projects is that it contributes to the cult of overengineering that plagues the industry. People seem to grow up thinking they need innumerable layers of abstraction to do things, when often they have actually made their solution not only inefficient, but actually less stable and more difficult to develop.
      - segfaultbuserr 8y ago
        +1. Another criticism is consumerism - the hype that some of these devices created was more about purchasing and plugging boards and calling a library, without actually help hobbyists to learn something. Or as John Carmack has said, low-level programming is good for the programmer's soul, it's hard to imagine that programmers do have souls if they has never been exposed to low-level programming. Unfortunately, in the modern computing world, the chances are becoming fewer and fewer, most systems are far beyond a complete understanding for most people. I think I'll never completely understand the x86_64 instruction set (w/ SSE, SSE2, FMA, AVX), or the signal path of the PCI-E interface on my motherbard. Recently, I think some popular microcontroller projects may be the solution for a bare-metal programming experience. But we can also looking it from another perspective - the proliferation of mobile devices changed everything, nowadays, even using a general purpose computer is not an experience that many members of the new generation may have (there was a Hacker News article about it). Some don't understand a hierarchical filesystem of files and directories anymore, and others have problem typing on a physical keyboard. In this sense, to blink an LED on Raspberry Pi is already a big step forward, and it was exactly the motivation behind Raspberry Pi.
- ken 8y ago
  > Ironically, in the early 80s, we did it mainly because of the shortage of computing power, so we needed lots of co-processors. I'm not sure I entirely believe that explanation. Back in 1982, the Commodore 1541 [1] was basically another C=64 with no keyboard, and a built-in floppy disk. It was big and heavy and hot and not terribly reliable. 4 years earlier, the Apple's Disk II [2] was tiny, light, and had only 5 ICs [3] -- it was described as "a state machine made of a prom and a latch" [4]. The computer's CPU drove it -- it's not like the 6502 would otherwise be running other threads or processes during I/O! [1]: https://en.wikipedia.org/wiki/Commodore_1541#/media/File:Commodore-64-1541-Floppy-Drive-04.jpg https://en.wikipedia.org/wiki/Commodore_1541#/media/File:Com... [2]: https://www.youtube.com/watch?v=ESDANSNqdVk&t=28m30s https://www.youtube.com/watch?v=ESDANSNqdVk&t=28m30s [3]: https://www.folklore.org/StoryView.py?project=Macintosh&story=Nybbles.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... [4]: https://www.folklore.org/StoryView.py?project=Macintosh&story=Macintosh_Prototypes.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...
  - rasz 8y ago
    Apple didnt run a microchip fab manufacturing 80% of chips inside 1541, hence no incentive to sell you overpriced garbage (like C128D with 3 CPUs, 2 doing nothing all the time).
    - EvanAnderson 8y ago
      Yet Commodore's "overpriced garbage" was sold at retail prices consistently lower than Apple's, and had graphics and sound capabilities that far-exceeded the comparable Apple machines.
    - bsder 8y ago
      Um, the C64 sold 25 million units to the Apple II's 6 million. The VIC 20 was the first computer to sell a million units. The problem was that the C64 never really sold to businesses. If you were buying Visicalc, you bought an Apple II.
      - lscotte 8y ago
thinkmassive 8y ago
And the original Apple LaserWriter was the company's most powerful computer at its launch! "With its 12 MHz 68000 CPU, the LaserWriter was 50% more powerful than existing Macs, and with the 1.5 MB of memory necessary to download Postscript fonts and print a page at full 300 dpi resolution, it had three times as much memory as the top-end Mac." http://lowendmac.com/1985/apple-laserwriter/ http://lowendmac.com/1985/apple-laserwriter/
emptybits 8y ago
An impressive trick at Commodore users group meetings was to run Fast Hack'em for the 1541. This was a low-level floppy copier that ran on one or more 1541s, without the need for a host C64 once the process started. i.e. you'd start connected like this: (drives were daisy chained) [C64]--[1541]--[1541] Then remove the C64 and dupe away for the rest of the evening, swapping in disks as they completed. [C64] [1541]--[1541]

segfaultbuserr 8y ago

Ironically, in the early 80s, we did it mainly because of the shortage of computing power, so we needed lots of co-processors. And now we are still doing it, but mainly due to our excessive computing power. Want to blink an LED? Let's put Linux, Apache and Ethernet in the circuit. ;-) Well, on the other hand, it's unfair to say it's an abuse of computing power, since if you do have the power, making autonomous devices does make a system much more elegant and manageable, and not even talking about the advantages of general processor over specialized chips. Take another look, it also tells us something about early home computer designs - the actual CPUs were usually irrelevant, there were no technical difficulties on the CPUs themselves and you could easily put TWO CPUs in a hard drive. And unlike modern computers, it was not even the most expensive part and the choice was limited, a cheap "trainer" computer with only hexadecimal keyboard, and an expensive home computer with a color CRT often shared a single CPU. The vast majority of the cost and troubles was system design, or putting these parts into a usable computer, with your own solution of input, storage, interface, graphics, software, or a chassis. The standardized IBM PC hasn't came yet, and one needed to create a solution of every subsystem. Every computer was a unique design, often with custom-made ASIC chips for peripherals.

pjmlp 8y ago
To be fair something like an ESP32 runs circles around the PCW1512, which we had on the school computer club, where we spent countless hours playing Defender of the Crown. So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices. Naturally it depends on the use case.
- segfaultbuserr 8y ago
  > So we don't have to necessarily constrain ourselves to Assembly and C on those tiny devices. Good point. > something like an ESP32 runs circles around the PCW1512, which we had on the school computer club I think as long as people are having fun with them, the hardware already served a good purpose. Even if the LED blinking is implemented by running Linux. But in my opinion, people who are interested in these popular embedded boards should also learn about the basis of electronics, or just be aware of its existence, and understand the things one could do without buying a premade "board", and that it's possible to blink an LED with a few transistors. Well, I think most will find out by themselves, it's just a matter of time and guidance.
  - AnIdiotOnTheNet 8y ago
    My problem with using things like the RPi for such simple LED blinking projects is that it contributes to the cult of overengineering that plagues the industry. People seem to grow up thinking they need innumerable layers of abstraction to do things, when often they have actually made their solution not only inefficient, but actually less stable and more difficult to develop.
    - segfaultbuserr 8y ago
      +1. Another criticism is consumerism - the hype that some of these devices created was more about purchasing and plugging boards and calling a library, without actually help hobbyists to learn something. Or as John Carmack has said, low-level programming is good for the programmer's soul, it's hard to imagine that programmers do have souls if they has never been exposed to low-level programming. Unfortunately, in the modern computing world, the chances are becoming fewer and fewer, most systems are far beyond a complete understanding for most people. I think I'll never completely understand the x86_64 instruction set (w/ SSE, SSE2, FMA, AVX), or the signal path of the PCI-E interface on my motherbard. Recently, I think some popular microcontroller projects may be the solution for a bare-metal programming experience. But we can also looking it from another perspective - the proliferation of mobile devices changed everything, nowadays, even using a general purpose computer is not an experience that many members of the new generation may have (there was a Hacker News article about it). Some don't understand a hierarchical filesystem of files and directories anymore, and others have problem typing on a physical keyboard. In this sense, to blink an LED on Raspberry Pi is already a big step forward, and it was exactly the motivation behind Raspberry Pi.
ken 8y ago
> Ironically, in the early 80s, we did it mainly because of the shortage of computing power, so we needed lots of co-processors. I'm not sure I entirely believe that explanation. Back in 1982, the Commodore 1541 [1] was basically another C=64 with no keyboard, and a built-in floppy disk. It was big and heavy and hot and not terribly reliable. 4 years earlier, the Apple's Disk II [2] was tiny, light, and had only 5 ICs [3] -- it was described as "a state machine made of a prom and a latch" [4]. The computer's CPU drove it -- it's not like the 6502 would otherwise be running other threads or processes during I/O! [1]: https://en.wikipedia.org/wiki/Commodore_1541#/media/File:Commodore-64-1541-Floppy-Drive-04.jpg https://en.wikipedia.org/wiki/Commodore_1541#/media/File:Com... [2]: https://www.youtube.com/watch?v=ESDANSNqdVk&t=28m30s https://www.youtube.com/watch?v=ESDANSNqdVk&t=28m30s [3]: https://www.folklore.org/StoryView.py?project=Macintosh&story=Nybbles.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... [4]: https://www.folklore.org/StoryView.py?project=Macintosh&story=Macintosh_Prototypes.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...
- rasz 8y ago
  Apple didnt run a microchip fab manufacturing 80% of chips inside 1541, hence no incentive to sell you overpriced garbage (like C128D with 3 CPUs, 2 doing nothing all the time).
  - EvanAnderson 8y ago
    Yet Commodore's "overpriced garbage" was sold at retail prices consistently lower than Apple's, and had graphics and sound capabilities that far-exceeded the comparable Apple machines.
  - bsder 8y ago
    Um, the C64 sold 25 million units to the Apple II's 6 million. The VIC 20 was the first computer to sell a million units. The problem was that the C64 never really sold to businesses. If you were buying Visicalc, you bought an Apple II.
    - lscotte 8y ago

thinkmassive 8y ago

And the original Apple LaserWriter was the company's most powerful computer at its launch! "With its 12 MHz 68000 CPU, the LaserWriter was 50% more powerful than existing Macs, and with the 1.5 MB of memory necessary to download Postscript fonts and print a page at full 300 dpi resolution, it had three times as much memory as the top-end Mac." http://lowendmac.com/1985/apple-laserwriter/ http://lowendmac.com/1985/apple-laserwriter/

emptybits 8y ago

An impressive trick at Commodore users group meetings was to run Fast Hack'em for the 1541. This was a low-level floppy copier that ran on one or more 1541s, without the need for a host C64 once the process started. i.e. you'd start connected like this: (drives were daisy chained) [C64]--[1541]--[1541] Then remove the C64 and dupe away for the rest of the evening, swapping in disks as they completed. [C64] [1541]--[1541]