"I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned to make my own. I then thought using premade skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all."
Sure none of these are “cheating”, but someone somewhere has to do each of those things, and the further down the chain you go, the more “control” you get over your sound and composition. The law of diminishing returns of course hits at some point (although someone may argue that their breed of goats has a certain sound they can’t get any other way).
It’s the same thing in programming: someone chaining together libraries may eventually run into a point where there’s nothing out there that does exactly what they need. That doesn’t mean it’s not your work unless you’ve written the compiler yourself, or have your own fab in your garage, it just means you have to be aware of the degree of control you give up the higher level you go.
As you say, the reality of it is that there are thresholds, for some where the benefit cost ratio is poor enough few will break through it from a higher level use... and then there are lower ratio thresholds in between where you will get various proportions of experienced people who want a little more control (in different directions) breaking through.
But even with those thresholds (in this case one IC vs another IC), it's arbitrary and subjective, you are just choosing to spend your time and effort in a different way.
Really depends on what's the length of samples and how exactly are you working with them. With whole musical phrases (as used in 90s hip-hop and french house, for example), it's really more like arranging. But when you cut those very samples just a little bit shorter, and start playing MPC pads like an instrument, I'd argue you switch back to composing.
In many ways watching people describe and choose their spot in the "grab package" <-> "herd goats" spectrum is my favourite part of AoC each year¹. The squirming some people choose to do when justifying their place in a table of magic internet points is a lot of fun.
Edit: Should add I'm one of those squirmers too, often when I'm thinking about networkx/numpy/etc.
I can personally see the discussion of how to work with a basic installation being worthwhile, as I know I'm guilty of "why don't you just $bunch_of_experience_option?". However, I don't think I'd want to try to do actual work without the tools I have and the tools I make.
No one sees?! What do you mean? That’s literally the punch line of the joke.
Of course ‘learning things’ is a secondary benefit, especially if that’s actually one of the goals you specifically set out for. Still I’ve personally watched programmers live that joke, and overengineer something that could take a day into a year long project, to solve a problem they didn’t have. I’ve seen it enough and cause enough problems that I try hard to write code with specificity and stick to the problem at hand. So much so that I have an actual problem with not abstracting things soon enough. ;)
Looking at Ben Eater's youtube channel, there seems to be a healthy demand for building more authentic '80s 8-bit systems.
If one's goal is to learn about how to build an 8-bit computer, using a microcontroller is not going to be an edifying experience unless the goal is to do something mostly in the software domain like write a simple OS.
While I think your parable is good advice for getting a business going quickly, it's not appropriate for deep dive learning or hacking.
But the fact that it's a microcontroller rather than a microprocssor bugs me. The lack of an external memory bus feels incredibly in-authentic to me.
Yep. It's still a neat project, but don't claim to build an 80's computer using "only 5 chips" when they're more modern chips that allow that low count. A single FPGA can do it all too.
On a tangent, I'm curious about upgrades to old machines that could have been done at the time. For example, my Interact has super low-res graphics where each pixel is 3 scan lines high. That machine was designed for 4-8K of ram but shipped with 16K and had an upgrade to 32K. It seems like increasing the vertical resolution should have been a fairly trivial hardware hack since the RAM is all there. Bumping the horizontal resolution might have been possible but harder. Increasing the available colors should have been fairly easy. It seems to be a case of not enough time for the design to bake. The other 8bit machines with ASICs might not be so incomplete, but there may still be some things that could have been done.
E.g. on the C64 the CPU and graphics chip competes for memory cycles all the time. This is why the screen blanks when loading, for example - to prevent the graphics chip from "stealing" cycles. A more expensive memory subsystem would allow working around that, and speed up the entire thing. This is a recurring issue with many other architectures as well for cost saving reasons (e.g. the Amiga "chipram" vs "fastram" distinction).
From 1983, the 8/16-bit 65C816 (used in the Apple IIGS) would have been a more natural choice for the C128 or even a "revised" C64 (at the cost of some compatibility), and reached clock rates up to 14MHz.
A lot of it was also down to market pressure and R&D costs... All of the home computer manufacturers led precarious existences, as evidenced by most of them failing or transitioning out of that market (and often then failing); at its peak, Commodore was notorious for being tight fisted and spending ridiculously little money on R&D relative to its size, and that was probably what made it survive as long as it did despite serious management failures, while Apple largely survived by already then going after a less cost-sensitive market segment and much higher margins.
The list of R&D efforts in Commodore that were shut down not because they were not technically viable, but because the company wouldn't spend money on them (or couldn't afford to) is miles long. I'm sure the same was true in many of the other companies of the era (but I was a C64 and Amiga user, and so it's mostly Commodore I've read up on..)
We could certainly have had far more capable machines years earlier if a handful of these companies had more money to complete more of these projects and/or if there had been demand for more expensive machines at the time.
But then progress is very often limited by resource availability, not capability.
Sometimes it's pretty blurry what is a microcontroller and what is a microprocessor. The PIC32MZ/DA has an integrated Graphics Controller and 32MB of DRAM.
That’s a cool PIC32 home computer - PIC32 is MIPS btw far beyond the old 8 bits though...
And the hack was good enough.
It is one of the things in which academical training is perverse. It trains you to always complicate more and more any subject, and that the hard work is the goal, shortcuts are not permitted.
It begs the question what was done in parts of the world that didn't use NTSC, though.
https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga...
The ZX80 used 21 (IIRC) off-the-shelf TTL chips.
The truth is that we live in magnificent times where there's a wide range of choice on how to do things and it is amazing.
If your goal is faithful retrocomputing, then sure, an ATMEGA is out of the question v., say, a 6502 or Z80.
If your goal is minimalism or simplicity, then an ATMEGA is perfectly viable as a way to get there.
[1] - https://eater.net/vga