How Many Commodore 64s Does It Take?

[Winston]

How Many Commodores Does It Take To Crack A Nut?
September 7, 2019

https://hackaday.com/2019/09/07/how-many-commodores-does-it-take-to-crack-a-nut/

It’s brilliant enough when composers make use of the “2SID” technique to double the channels in a Commodore 64 with two sound chips, but even then some people like to kick things up a notch. Say, five times more. [David Youd], [David Knapp] and [Joeri van Haren] worked together to bring us just that, ten Commodore computers synchronously playing a beautiful rendition of the Dance of the Sugar Plum Fairy at this year’s Commodore Retro eXpo.

The feat is composed of nine Commodore 64 computers and one Commodore 128, all fitted with the SID chip. It is a notorious synthesizer chip for utilizing both analog and digital circuitry, making each and every one of its revisions unique to a trained ear, not to mention impossible to faithfully reproduce in emulation. The SID was designed by Bob Yannes at MOS Technology, who later went on to co-found Ensoniq with his experience in making digital synthesizers.

How this orchestra of retro computers came to be, including details on how everything is pieced together can be found on this slideshow prepared by the authors of the exhibition:

https://youdzone.com/c64/orchestrionSlidesV1.0.pdf

It’s interesting to note that because of timing differences in each computer’s crystal clock and how only the start of the song is synchronized between them, they can’t play long music tracks accurately yet, but a 90-second piece works just fine for this demonstration.

These synthesizer chips are slowly going extinct since they’re no longer being manufactured, so if you need a new replacement solution, FPGAs can fill that SID-shaped hole in your heart. If you need the whole computer though, the newer Teensy 3.6 will do just fine emulating it all.



The Tuneful Eight

Evoke 2019: 2nd place in the "Alternative Platform Compo" - "The Tuneful Eight"

The hardware used is an Ultimate64 Elite with two additional FPGASIDs. The Ultimate64 is running with a special firmware, that is capable of handling 2x4 UltiSIDs. In the demo 2x2 UltiSIDs together with 2x2 FPGASIDs were used.

 

[BEC]

There was a time when we had three C-64 systems up and running and in active use in this house....but I never tried to link them together like that. Cool!

 

[prfesser]

One of these days I gotta get my C64 down from the attic and see if it (and the disk drive) still works. Have a Batteries-Included BI-80 card, for an 80-column display back when 40 columns was a common standard.

Wrote the text of my Ph.D. dissertation on the C64, two floppy disks. I wish that MS Word would do some of what the C64 could do---e.g., superscript, subscript, underline, italics, or boldface a single character with a single command. You pressed the two keys for the command, then typed the character to be 'enhanced'. It automatically turned off the enhancement after that single character. Very useful when writing a lot of chemical formulas with subscripts.

On Word and WordPerfect you have to turn on the enhancement, then turn it off.

 

[Bat-mite]

I had a C64 with the music writing software. Throw notes on a staff, pick an instrument, and play your tune. Good times! Had to be mid-1980s. I also used the C64 and a dial-up modem to access machines at my university campus. So long ago ....

 

[Winston]

One of these days I gotta get my C64 down from the attic and see if it (and the disk drive) still works. Have a Batteries-Included BI-80 card, for an 80-column display back when 40 columns was a common standard.

Wrote the text of my Ph.D. dissertation on the C64, two floppy disks. I wish that MS Word would do some of what the C64 could do---e.g., superscript, subscript, underline, italics, or boldface a single character with a single command. You pressed the two keys for the command, then typed the character to be 'enhanced'. It automatically turned off the enhancement after that single character. Very useful when writing a lot of chemical formulas with subscripts.

On Word and WordPerfect you have to turn on the enhancement, then turn it off.

The standard now for C64 longevity extension is to replace all of the electrolytic capacitors, especially if it's been in a high ambient temperature location like an attic. Also, definitely test the output voltages from the power supply brick for proper voltages and any AC component on what is supposed to be a DC voltage before attempting to use it as it has some very large electrolytic caps. If your disk drive has a rubber belt it is almost certainly shot from the heat, but you can buy replacements on-line. All of the fix-it tutorials can easily be found on YouTube. That said, here's a miracle:

Commodore 64 left outside for over a decade! Could it still work??

I was given a Commodore 64C that had been left outside for a decade or more in rural Oregon. It dealt with everything mother nature could throw at it while it sat outside. Could this machine possibly still work?

 

[Winston]

Commander X16 - modern 8-bit retro computer project

Very clever retro-hardware architecture using old IC types still in production, but they already have a decent emulator to aid hardware development which will only get better with time. Some people simply must have hardware but, for instance, as an Amiga expert/fanatic on YouTube has demonstrated and admitted, the fastest, cheapest by far, and most convenient (USB I/O, HDMI out, etc.) Amiga system is one emulated on a Raspberry Pi.



Emulator:

https://github.com/commanderx16/x16-emulator/releases

 

[Alan15578]

Thanks. I could go on endlessly about the C64 and 128, but this is OT. I Used to follow the CBM newsgroup, but I quit doing that 15-20 years ago. A 128D still occupies real estate on my desktop, but I have not turned it on in 10 years or so. Could you provide a few good links to get reconnected and updated?

I was never interested in sound, music, or gaming, but I did try using the SID as signal generator for some structural vibration excitement. I could scroll though the frequencies using two game paddles. Trying to generate higher frequency sinusoidal waves by selecting SID waveforms and trying to isolate the second fundamental frequency by filtering was interesting. I also wanted to think up some way sprites, or sprite collision detection could be used effectively in a computing or engineering application.

 

[Alan15578]

I wrote many model rocket related programs on my C64. The last major program I wrote was a CFD program in 1990 that I have never reported on, so I'll share that story here. First, I am an aerospace engineer, but not strictly an aerodynamicist or CFD expert. I will not be offended if a "real" CFD expert corrects some of my misconceptions. I would have been a natural to go into CFD as an undergrad student in the mid to late 70's. However, the future of CFD then was tied to blue sky growth in computing power, and I did not believe that computing power would increase as far and fast as it has. Today we are hitting the wall, but largely circumventing it by massive parallel processing and computer networking. There are two main approaches to CFD, one is using some mathematical constructs that approximate airflow, with some limitations, the other is applying "real" aerodynamic equations such as the Naiver-Stokes equations. The former can be quite tractable using sources, sinks, and vortices, but technically only works for attached incompressible flow without boundary layers. The latter has to fill the volume of space around the object with many elements and solve the resulting system with a finite element or finite difference approach, resulting in a huge number of equations that must be solved simultaneously. Normally solving a linear system of equations takes n squared memory and requires k n cubed mathematical operations. So to solve problems on a C64, we need to keep n reasonably small, and only the simple form of CFD is possible. "real" CFD used to take super computers with massive storage capability, but now some problems can be solved on a PC, but I'm leaving much unsaid.

The problem I actually wanted to solve is the inverse design problem, where you specify the desired local air speeds and generate the shape that would produce it. This is quite elegant in 2-d and is commonly used in airfoil design, using a vortex method. The idea is to specify a flat velocity profile over as much of the front portion of the airfoil as possible, to maximize the laminar flow portion, followed by a "transition ramp" that encourages the flow to transition to turbulent, and continue to the trailing edge without separation. In 3-d the inverse design problem not elegant, but for bodies of revolution can still be done. What I actually wanted to do was a constrained optimization problem. I was thinking that I could design a generic FAI fat body rocket with maximum laminar airflow, and a minimum drag boat tail. I had found all the bits and pieces that I needed in published literature, and I just need to do the work and put it all together. The first step was the CFD part.

I found a paper on a higher order surface-source method for bodies of revolution. So instead of using many flat elements to define the meridian of the body of revolution, I could use fewer curved elements, resulting in higher accuracy with a smaller n. Furthermore, they used a solution routine called quartersolve that only requires 1/4 of the n squared memory that I was expecting. I had been so entrenched in the LInpack, Lapack, etc. routines that I had forgotten something that I had learned in high-school, solving linear equations with pencil and paper. What I need to compute was Ax=y, Bx=z. A and B are n by n square matrices that are computed from the shape of the body of revolution, x,y, and z are column vectors. Solving for x, the surface source strengths, is the hard part, and z is the desired airspeed tangent to the body meridian. As it turns out, A is diagonally dominant and graded so that we can stably solve for x directly with out any partial pivoting or factoring of A. A and B are efficiently computed together, one row at a time. B could easily have been written to external storage and read back in later. However, I had enough memory in the C64 that I kept B in memory and solved for x with almost no additional memory! Solving for x still required 1/4 n squared memory, but it is actually more like a quadratic memory requirement. Halfway through the computation this maximum memory is required, but it actually decreases as each additional line is processed. So, I had n squared workspace allocated, and filled it with rows of B from the bottom up, toward the end, rows of B were filling in memory that the solution of Ax=y no longer needed. I did a lot of numerical analysis on this portion of the problem and the results were quite good.

Depending on the size of n, it might take 20 minutes or two hours to compute. I would even let it run overnight. However, I decided that solving the inverse problem on the C64 would be painfully slow, and the more interesting optimization problem even more so.

 

[Winston]

Thanks. I could go on endlessly about the C64 and 128, but this is OT.

Close enough as far as I'm concerned since this thread can also be about retro-computers back when they weren't retro. This Watering Hole forum section can be about anything and I especially don't think anything technical is off limits.

A 128D still occupies real estate on my desktop, but I have not turned it on in 10 years or so. Could you provide a few good links to get reconnected and updated?

Oh, there is TONS of that stuff on YouTube to find as well as to be found via Google searches. I wish I had saved every computer I've bought and built, but moving around in the USAF didn't make that easy PLUS, even more of a factor, I didn't even THINK to keep them.

 

[Winston]

I wrote many model rocket related programs on my C64. The last major program I wrote was a CFD program in 1990 that I have never reported on, so I'll share that story here. First, I am an aerospace engineer, but not strictly an aerodynamicist or CFD expert. I will not be offended if a "real" CFD expert corrects some of my misconceptions. I would have been a natural to go into CFD as an undergrad student in the mid to late 70's. However, the future of CFD then was tied to blue sky growth in computing power, and I did not believe that computing power would increase as far and fast as it has. Today we are hitting the wall, but largely circumventing it by massive parallel processing and computer networking. There are two main approaches to CFD, one is using some mathematical constructs that approximate airflow, with some limitations, the other is applying "real" aerodynamic equations such as the Naiver-Stokes equations. The former can be quite tractable using sources, sinks, and vortices, but technically only works for attached incompressible flow without boundary layers. The latter has to fill the volume of space around the object with many elements and solve the resulting system with a finite element or finite difference approach, resulting in a huge number of equations that must be solved simultaneously. Normally solving a linear system of equations takes n squared memory and requires k n cubed mathematical operations. So to solve problems on a C64, we need to keep n reasonably small, and only the simple form of CFD is possible. "real" CFD used to take super computers with massive storage capability, but now some problems can be solved on a PC, but I'm leaving much unsaid.

The problem I actually wanted to solve is the inverse design problem, where you specify the desired local air speeds and generate the shape that would produce it. This is quite elegant in 2-d and is commonly used in airfoil design, using a vortex method. The idea is to specify a flat velocity profile over as much of the front portion of the airfoil as possible, to maximize the laminar flow portion, followed by a "transition ramp" that encourages the flow to transition to turbulent, and continue to the trailing edge without separation. In 3-d the inverse design problem not elegant, but for bodies of revolution can still be done. What I actually wanted to do was a constrained optimization problem. I was thinking that I could design a generic FAI fat body rocket with maximum laminar airflow, and a minimum drag boat tail. I had found all the bits and pieces that I needed in published literature, and I just need to do the work and put it all together. The first step was the CFD part.

I found a paper on a higher order surface-source method for bodies of revolution. So instead of using many flat elements to define the meridian of the body of revolution, I could use fewer curved elements, resulting in higher accuracy with a smaller n. Furthermore, they used a solution routine called quartersolve that only requires 1/4 of the n squared memory that I was expecting. I had been so entrenched in the LInpack, Lapack, etc. routines that I had forgotten something that I had learned in high-school, solving linear equations with pencil and paper. What I need to compute was Ax=y, Bx=z. A and B are n by n square matrices that are computed from the shape of the body of revolution, x,y, and z are column vectors. Solving for x, the surface source strengths, is the hard part, and z is the desired airspeed tangent to the body meridian. As it turns out, A is diagonally dominant and graded so that we can stably solve for x directly with out any partial pivoting or factoring of A. A and B are efficiently computed together, one row at a time. B could easily have been written to external storage and read back in later. However, I had enough memory in the C64 that I kept B in memory and solved for x with almost no additional memory! Solving for x still required 1/4 n squared memory, but it is actually more like a quadratic memory requirement. Halfway through the computation this maximum memory is required, but it actually decreases as each additional line is processed. So, I had n squared workspace allocated, and filled it with rows of B from the bottom up, toward the end, rows of B were filling in memory that the solution of Ax=y no longer needed. I did a lot of numerical analysis on this portion of the problem and the results were quite good.

Depending on the size of n, it might take 20 minutes or two hours to compute. I would even let it run overnight. However, I decided that solving the inverse problem on the C64 would be painfully slow, and the more interesting optimization problem even more so.

I don't think I ever did anything that complex, but I wrote a solid rocket motor simulator on my Atari 1040ST in the excellent GFA BASIC using "Rocket Propulsion Elements" which I then used to simulate a specific Vulcan composite motor burn, one for which there was incredibly detailed info about including complete propellant characteristics, a simulation which turned out to be amazingly in line with the motor's actual test data. In college, I wrote a machine language program on an 8080 microprocessor trainer to quickly go/no-go test all of of the bazillion 7400 series ICs in the lab parts drawers using a ZIF socket. On the 1040ST again and using the fortunately outstanding tech data for a piece of microwave transceiver gear, I wrote a program to generate the hexadecimal frequency synthesizer code which I then burned into the present, but blank (since that feature wasn't bought) EPROMS in the equipment to add a very convenient feature. I did other fun and simple stuff like program the "Bogus Sort" humorously described in Byte Magazine which was a sort done by "throwing" a "deck of cards" into the air and then "picking them up" in string order to see how many tries it would take to get a proper sequence of X cards. I let it run overnight on the 1040ST and the longest sequence was three cards after tens of thousands of attempts.