From: David Wood (jbevren_at_starbase.globalpc.net)
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 collissions. 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 (151, 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. -jbevren 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.