Yeah, unfortunately, the C64 couldn't offer you that, at least not in that generality. For one, it only supported 16 fixed colors, not RGB values. On top of that, its 320x200 pixels could not be addressed individually unless you constrained yourself to monochrome, i.e., only two colors: one background and one foreground colors (out of the 16 mentioned above). There were, of course, graphics modes that allowed more colors but in return gave you more restrictions on the solutions.

Interestingly, by abusing some architectural oddities, people have been able to create new graphics modes on the 64 that support more colors than the original 16 and in hi-res. But it's still not as easy as set pixel (x, y).

And here are some of the "architectural oddities":

Flicker free 320x200 high res on C64 (flicker free starts at 42s):

https://www.youtube.com/watch?v=Vcm0ecni5d4

This one's flickery, but still pretty nice:

https://www.youtube.com/watch?v=BjcQwCWnMoI

I never knew the C64's built-in BASIC had no high-level graphics (and, seemingly, audio?) interface. It seems like a crazy thing to leave out but doesn't appear to have affected the popularity of the machine (to say the least).

Brian Bagnall’s “Commodore: A Company On the Edge” covers the history of the PET, VIC-20, and C64. There was no master plan that anyone could stick to for more than six months (the management stories are horrifying) and the C64 was a last minute whiptogether. They didn’t have enough time to add the better BASIC that they’d already developed on another project, so it shipped with the same lousy BASIC as the VIC-20 had. If you fondly remember Commodore from those days, the book is worth reading. It made me appreciate how much was achieved despite an inadequate CEO and board.

Sweet, thanks, I picked it up. also /wave!

/wave back ... Dude, LONG time!

I seem to recall a command on the Commodore 128 that was like PLAY “FFGEFG” to play musical notes.

Yeah, too bad the graphics modes of C64 were "text modes" of a couple different character sizes and a redefinable 8-bit charset. Colors were from a fixed, but carefully designed 16-color palette on the VIC-II chip itself. Due to the character graphics limitation, the colors couldn't be placed anywhere, but more like in a foreground/background color style selection within the character grid, although some lower res mode allowed four colors within the same "character" space. Additionally, there was an overlay layer of a few one-colored-each sprites (non-color bits were transparency). Sprites were limited in size but not in placement and were as close to straight-forward pixel-based single-color graphics you'd get on a C64.

Video RAM was expensive back then, so the common "gaming" hardware worked around the issues in ways that made use of graphics as independently colored pixels very difficult, and this includes things like the game consoles, Amigas and Atari STs and their lack of chunky graphics modes.

A Macintosh II with a full-color display card and an RGB display from 1987 could be one of the oldest commodity hardware setups that could do what you ask for; simple fully buffered frame buffer supporting 24bit RGB colors. VRAM-wise they were 32bit really, but 8 bits per pixel were wasted, because RGBA wasn't supported and it wasn't until early 90s Apple supported 16bit modes; 1/2/4/8/24bit graphics were your only options on Macs until then. They had accelerated 2D drawing primitives from the OS / graphics card firmware-driver (Color QuickDraw) supporting with APIs doing what you describe and in a way where your software wasn't dependent on the hardware implementation; software written for them would work until 2006 and the Intel Macs, and discontinuation of the Classic environment in Mac OS X 10.5 Leopard on the PPC Macs.

Some nonstandard "extended" VGA cards before VESA standardization of "SVGA modes" could also do it by late 80s/early 90s, but those were pretty much hardware-dependent and you had to use them at bare metal until OS / driver support for such came around in Windows 3 times. Some MS-DOS software, like Deluxe Paint would support many of them though.

    var canvas = document.getElementById('canvas');
    var ctx = canvas.getContext('2d');
    
    ctx.fillStyle = `rgb(${r}, ${g}, ${b})`;
    ctx.fillRect(x, y, 1, 1);

I say it's pretty close.

It's pretty amazing to me that in 2018, the way we pass colors to a modern graphics API is to build a string with comma separated list of the individual components encoded in decimal.

And then people wonder why computers feel slower than they did 15 years ago.

Legacy APIs for DOM are hard to get rid of, which the Canvas API is based on. There is some progress though: https://developers.google.com/web/updates/2018/03/cssom

You can save this as an HTML file:

  <canvas id="canvas" width="400" height="400"></canvas>

  <script>
  var canvas = document.getElementById('canvas');
  var ctx = canvas.getContext('2d');
  var width = canvas.width;
  var height = canvas.height;
  var imagedata = ctx.createImageData(width, height);

  function draw(r, g, b, x, y){
    var pixelindex = (y * width + x) * 4;
    imagedata.data[pixelindex] = r;
    imagedata.data[pixelindex+1] = g;
    imagedata.data[pixelindex+2] = b;
    imagedata.data[pixelindex+3] = 255; //alpha
    ctx.putImageData(imagedata, 0, 0);
  }

  </script>

This gives you a 400x400 space to draw on. Open the console and call draw().

  draw(0,0,0,15,15);

LOL, not even close.