C64 Keyboard Prototype | Hacker News Reader

C64 Keyboard Prototype

breadbox64.com

68 pointserickhill33 comments

Keyboard is pretty amazing for C64 preservation efforts. Perhaps lessons learned could be applied to other same era systems.

There's one part in C64 that's becoming more and more rare — the amazing SID sound chip.

I wonder whether it'd be possible to have production runs of truly new 6581 and/or 8580 SID chips. Does someone still have the old masks?

Other chips you could emulate with an FPGA. But SID is partially analog, so it's special. Some say no two SIDs sound the same.

Btw, recent C64 music demo playing off 1 MB Ocean style (= ROM) cartridge (not REU):

https://www.youtube.com/watch?v=7qxxnJVU4jQ

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

Yes, it's real. Not particularly good example of SID though, but still impressive for 1982/83 technology.

But this one does show off SID; C64 "Cubase", realtime DSP (timestretch, low/high pass filter, distortion, etc.) pretty amazing:

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

> Does someone still have the old masks?

You can probably reverse the masks with a microscope with a little elbow grease. Not trivial by any means, but doable by someone in a garage as a hobby.

The real question, does a fab that can work with that process still exist?

There’s an ongoing effort to understand the SID here

http://forum.6502.org/viewtopic.php?f=8&t=4150

Lots of interesting analog chip level stuff, it’s all new to me as I’ve only dealt with things at the digital level, but very interesting to see how the fabrication technology works in an analog way..

Not an EE, but might an FPGA be created to mimic one?

No, not for that. Its sound characteristics are from the physical layout of the chip and the individual differences from manufacturing is more notable on old revisions of 6581 than newer ones. 8580 models sound more or less identical to each other thanks to the improved manufacturing technology.

Well, while the sound is coming from the SID-chip, it actually is samples. The really impressive thing is that they can play samples even tough the SID-chip was not designed to play samples.

The author of "Cubase64" (Pex "Mahoney" Tufvesson) has written an interesting explanation of how it is made: https://livet.se/mahoney/c64-files/Cubase64_White_Paper_by_P...

The technique used in the two first links of parent comment, is, as I understand it, based on another work of Pex : https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_D...

None of those digitized things really are what the SID is about though, nor do they show it off for what it really is; a synthesizer for playing 3-channel tunes like these: https://www.youtube.com/watch?v=2wbwKdV89pE

For digitized sound, the SID isn't different from something like a PC beeper.

> None of those digitized things really are what the SID is about though

Fair enough. Although cubase64 does use SID features in an innovate way.

> For digitized sound, the SID isn't different from something like a PC beeper.

C64 is way superior for playing samples compared to PC beeper. Only commonality is that it takes high amount of CPU cycles, in the linked example all of it.

A PC beeper can sound just as good, when used on a fast enough PC and the beeper output is connected to something better than the built-in piezo speaker. Even on the original IBM PC, you could make it sound almost as good by very careful optimization and close to 100% of allocation of CPU cycles, like shown at the end of the 8088 MPH demo: https://youtu.be/hNRO7lno_DM?t=6m52s

We can agree to disagree, I just don't think PC beeper can in any realistic circumstances sound as good as this:

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

How about this? There are also plenty of DOS PC-speaker-savvy demos from the 90s on pouet.net and scene.org, but there are apparently no recordings of them on youtube without sound card configurations. Some of the late DOS games also had awesome PC-speaker support. There was also a Windows sound driver for the PC speaker in Windows 3.1 times, maybe Windows 95 as well. Basically; the faster the PC, the higher the sampling rate you can go. The sound output on Raspberry Pis and some of the cheaper USB sound cards are also very similar to having stereo PC speakers, since that's also about just dumb bit-banged PWM.

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

Not bad, but that C64 demo sounds clearly better. C64 can have something between 6-8 bits of resolution per sample using a trick invented by Mahoney (https://livet.se/mahoney/c64-files/Musik_RunStop_Technical_D...).

Mostly I remember this type of sound, even at higher sample rate: https://www.youtube.com/watch?v=1fErwWtkMS4

I wrote a noise shaping PC-beeper PWM converter in the nineties, oversampling at maybe 500 kHz or so. It still sounded very tinny. (First version was without shaping, and it had an annoying high frequency pitch.)

> Basically; the faster the PC, the higher the sampling rate you can go.

Not really, io-port (outb) encounters a brick wall pretty early. So no matter how fast the CPU is, you can't toggle the speaker any faster.

Those acrylic backing plates are going to crack at some point. The author should look into aluminum composite panel (Dibond is one brand name). It's a sheet of HDPE plastic sandwiched between two thin layers of aluminum, and is much stiffer and stronger than acrylic of the same thickness.

As a kid all I ever wanted from any computer was this:

Set pixel (x,y) to color (r,g,b)

I wish today’s kids had this with as little overhead as possible

    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.

LOL, not even close.

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

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

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.

Those keycaps are gorgeous. If someone could manage to get those manufactured I guarantee they would fetch upwards of $150/set on a site like massdrop.

I wonder how much it would cost to get custom keycaps made today with double-shot top and front legends.

Ask signature plastics! http://www.solutionsinplastic.com/

It just occurred to me that using the Commodore logo probably adds to the cost, as you'd have to license it from the company that owns the trademark. (The C64 Mini avoids using the logo, presumably for this reason.)

There's a set called SA Retro[1] that used the C64 logo; no idea if it was cleared or not.

[1]: https://www.geekzone.fr/wp-content/uploads/2015/09/Minila-Ai...

There has been an attempt at having them remanufactured, but the guy running the show isn't communicative and has had a lot of technical set-backs on the project. They're not dual-shot either, so more like the newer C64C model keys with printed markings. I'm one of the backers: https://www.indiegogo.com/projects/brand-new-colored-keycaps...

Reply on news.ycombinator.com