Re: C64 cluster

From: David Wood (
Date: 2007-11-07 04:37:00

This is a reply to several of the replies in the thread..

Interface:  User port.  Not parallel, but rather serial.  Think: 1571/1581
burst transfers.

Network: Half-duplex packet-based bus network (think: Model railroad DCC
system).  Collision detection is done by using both serial ports linked
together: When you transmit a byte, you also recieve it.  Transmit, then
check to see if what yout ransmitted is what was seen on the line.  If not,
there was a collission with another node's data, and you need to retransmit
your data after a short/random delay.  This should be done after each byte
transmitted of course, so you dont flood the line with a packet full of

Network boot:  8k game rom. Simple enough.  This does exclude expansions
such as rr/net, ide64, etc, but that wouldn't be needed on a master host
node anyway; just the slaves.  The master node would load its network
support software from its local storage (15[478]1, ide64, cmdhd, RL, etc).
Using a game rom also allows one to fit an REU with said boot rom for
additional memory on a given node.

OS: To be written of course.  It should be fairly simple to include minimal
network transport routines in the game above/after the startup vector and
CBM80 sequence (via a jump table in the ideal setup).  After initialization,
a node's firmware can either request start code via broadcast or simply wait
for a job to be sent to it.

Line noise/reflection/interference:  Eliminate signal reflecitons and
ringing by terminating each end of the network pair with resisters (think:
SCSI, since the serial ports are OC outputs like classic SE SCSI, but with
less current sink).

Addressing:  For software-assigned addresses, the network boot rom could
broadcast a request for its address periodically until assigned one by a
master node.  How to deal with multiple systems crying for an address at
once is something I haven't yet worked out.  A master node assigning
addresses would need to be able to send the addressing reply back to a
specific node.  This brings up another concept. The address could be encoded
in hardware with dipswitches on the userport parallel lines.  This easily
lends up to 256 addresses, more than could easily be cabled to a 6526 serial
port without external drivers.

I had thought this through quite a few steps of the process but haven't ever
implemented it.  The CIAs' serial ports are specifically designed for this
sort of thing (bus attachment), making the design process simple.

Networking via the parallel port isn't that good of an idea.  You'd need 10
lines to do it (8 data, one ground, one framing bit).  The serial idea uses
two lines.

If one wants to go complex with the whole ordeal, it would be possible to
use an ethernet-equipped microcontroller set up to recieve frames and DMA
directly to/from the C64's memory.  Control over /RESET would be a necessity
of course.  Reset could be held asserted until the node is sent a job, which
would be written in ram via DMA (with reset still held, to keep the cpu from
running) in the location the kernal expects to find a game rom.  Reset would
then be deasserted, allowing the commodore to start afterward.  The kernal
would then go through its normal init routines and find your code at $8000
and begin the job via jmp($8000).

IMHO the most elegant solution is the one that requires the least hardware.
An 8k rom to boot the c64 into network mode along with a simple 2-wire
network bus is about as cool as one can get.  Not nearly as fast as,
say, ethernet, but still fast enough for simple work.

For crashed nodes, consider some sort of watchdog circuit.  The kernal would
enable the 60hz interrupt (iirc?) before jumping to the game rom.  Just
build a circuit that waits 10 seconds for an irq and resets the system if
one doesn't occur.  A second watchdog concept would involve routing a timer
countdown to a user port pin via hardware.  This can be done, but I dont
remember which timer or which pin.  The pin would be tied to reset so that
when the timer counts down, the system is reset.  Just keep busily resetting
the counter in software or a (faster) IRQ routine so that it never counts
down and voila.  If the system crashes, the timer would count down and
reset to the game rom.  Use a timer in continuous mode ;)

Remember, we're not looking at SMP or even NUMA.  We're looking at a
networked cluster of inexpensive computers.  KISS and keep it inexpensive.


On Tue, 6 Nov 2007, Jim Brain wrote:

> Anders Carlsson wrote:
> > Marko Mäkelä wrote:
> >
> >
> >> loads 192+2 bytes [..] in 10 to 15 seconds.
> >>
> >
> > By the way, is it specified what the cluster will do? I saw that VCF
> > has planned a C64 cluster thrice since 1999, and once it was mentioned
> > to be used as a giant, 48 voice synchronized SID chip.
> >
> No, I noticed (while searching) that Sellam has been promising the
> cluster for some time (I saw a 2003 iteration of it as well), but no
> concrete details.  I had the idea of using all the monitors to play some
> game that showed on an 8 by 8 grid of screens, though that was just a
> dream for me, as I do not possess enough coding skills to pull that off.
> The sound option is cool as well (even in smaller numbers, like a 4
> machine cluster, you'd have 12 voices and 4MHz or so of processing power
> at your command), but the only other thing I could think of was a true
> multi-line BBS strapped to the Internet.
> But then, I'm good at thinking of the raw materials, and others are
> better at thinking of ways to use them.
> Jim
>        Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.