28 Jan
2008
28 Jan
'08
7:30 p.m.
Sellam wants to finish the 64 c64 cluster for the next VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
Jim
28 Jan
28 Jan
7:46 p.m.
On 1/28/08, Jim Brain <brain at jbrain.com> wrote:
Sellam wants to finish the 64 c64 cluster for the next
VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
Jim
UUCP? TCP/IP?
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
7:51 p.m.
On Mon, 2008-01-28 22:46:23 -0500, John Floren <slawmaster at gmail.com> wrote:
On 1/28/08, Jim Brain <brain at jbrain.com>
wrote:
Not really... Hardware is a C64. 64KB of RAM. Yes, of course, you can
implement enough of IP in 64KB to make it work, bit main purpose is
clustering, not building the largest wall of pingable C64 :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
Signature of: http://www.eyrie.org/~eagle/faqs/questions.html
the second :
I would think this would be a well researched and
innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
UUCP? TCP/IP?
8:21 p.m.
John Floren wrote:
UUCP? TCP/IP?
I'm looking more for the 802.3 or 802.6 stuff.
Jim
--
Jim Brain, Brain Innovations (X)
brain at jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com
8:19 p.m.
It was thus said that the Great Jim Brain once stated:
Sellam wants to finish the 64 c64 cluster for the next
VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
Each computer has two serial connections. Can you send and receive on a
single "port" at the same time? Can you send and receive on both
"ports" at
the same time? The design of the protocol depends somewhat upon the
capabilities of the ports. If you can't, then you might want something like
token ring, where a "transmit" token is passed around, and any computer with
the "token" can transmit. If you can send/receive without problems on
either port, then just let the computers transmit at will.
About the only real problem to come up is configuration---how does each
computer get its address on the network? Manual configuration? Automatic?
-spc (You might want to look at how AppleTalk works ... it's pretty neat
how it works ... )
8:36 p.m.
Sean Conner wrote:
Each computer has two serial connections. Can you
send and receive on a
single "port" at the same time? Can you send and receive on both
"ports" at
the same time? The design of the protocol depends somewhat upon the
The sync ports are unidirectional, but they can be run together, so an
SPI-like bus could be created.
capabilities of the ports. If you can't, then you
might want something like
token ring, where a "transmit" token is passed around, and any computer with
the "token" can transmit. If you can send/receive without problems on
either port, then just let the computers transmit at will.
On the latter, I don't understand. Who would they transmit to? How
would I deal with collisions?
About the only real problem to come up is
configuration---how does each
computer get its address on the network? Manual configuration? Automatic?
I cna hard code the addresses, but how does the ring/bus know when a
machine is alive, etc.
-spc (You might want to look at how AppleTalk works
... it's pretty neat
how it works ... )
I will look into it.
Jim
9:04 p.m.
It was thus said that the Great Jim Brain once stated:
Well, how does A know that its neighbor B is up? Just how many wires go
between A and B?
-spc (From the sound of it, it sounds like the answer is "one" ... )
Sean Conner wrote:
Since each computer is connected to two others, you end up with a ring
configuration (small example here):
A -- B -- C -- D
| |
E L
| |
F K
| |
G -- H -- I -- J
What I meant was that if A could transmit and receive from B and E at the
same time, then no tokens (more on that in a bit) are needed. Say, A wants
to talk to D; to do so, it needs to send a packet to B, which will then
forward it to C, which will forward it to D. Since the links are
bidirectional (in this hypothetical situation) A can talk to B or E at any
time.
If the links are unidirectional, then there has to be some way for A to
signal B that it has a packet to send its way---that is, if B isn't already
sending a packet to A. But first, you need to solve this situation:
A -- B
(a very simple network). A and B want to send each other a packet, at the
same time. How is this resolved? How you resolve this dictates the final
format of your protocol.
Each computer has two serial connections. Can
you send and receive on a
single "port" at the same time? Can you send and receive on both
"ports"
at
the same time? The design of the protocol depends somewhat upon the
The sync ports are unidirectional, but they can be run together, so an
SPI-like bus could be created.
capabilities of the ports. If you can't, then
you might want something
like
token ring, where a "transmit" token is passed around, and any computer
with
the "token" can transmit. If you can send/receive without problems on
either port, then just let the computers transmit at will.
On the latter, I don't understand. Who would they transmit to? How
would I deal with collisions? About the
only real problem to come up is configuration---how does each
computer get its address on the network? Manual configuration?
Automatic?
I cna hard code the addresses, but how does the ring/bus know when a
machine is alive, etc. 
9:20 p.m.
Jim Brain wrote:
I would think this would be a well researched and
innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
I would research Appletalk, and also -- don't laugh -- the Atari Lynx.
The Lynx could round-robin 8 units nicely with very little latency on a
serial link slower than yours.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
29 Jan
29 Jan
5 a.m.
With only 2 ports the best topology you can get is a ring.
You didn't say what you the application was, but i'll assume some
sort of demo-ware.
You might want to talk to all the nodes, so unique addressing might be
an issue. But more likely loop-less flooding is what you want. That
should be easy on a ring. if everyone has a unique id you just forward
(and copy) everything which you didn't send. or use a hop count which
starts at 64 :-)
You might look at the Amoeba o/s and implement a simple IPC like it did.
You could then distribute work via the IPC.
Since these are small machines you might also consider something more
like the original connection machine (CM-2). Everyone runs the exact
same code and you send results back and forth. You won't be synchronous
like the CM-2 but you could sync up with your serial ports. I'd bet you
could make some fun demo-ware with a few LED's on each machine (or 3,
like R,G,B)
-brad
7:15 a.m.
HI
With a ring, you could use a token but that would require
a master to start things and restore the ring when it was broken.
An alternative would be to allow a random machine to
become the master when a time had expired.
One could use a random number generator to determine
when any one machine chooses to be the master. Each would
hold off for some time and if no token showed, it would send
a token that had that machines ID. If another token showed
up with lesser priority ID, it would drop that token.
Each machine would wait for the sender of the highest priority
token sent to send a message that its token had made one loop,
before resumming normal messages.
If a higher priority token showed, it would know
that either the ring was still broken or some other system
was the now the master and had destroyed its token.
It would continue to watch the ring and if it didn't see a token
show after some time, it would hold off based on its random
value and then send a new token.
When the ring was restored, things would settle out.
All that is required is that each machine has a unique
ID.
Such a ring system could then be broken at any time to install
another machine or remove a machine.
Dwight
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail?-get your
"fix".
http://www.msnmobilefix.com/Default.aspx
7:33 a.m.
You don't need a ring to use token passing protocols.
There are some token passing protocols implemented
on bus structures (IEEE-802.4 (token bus), PROFIBUS, ...)
Just my 2c
Gerold
Am Di, den 29.01.2008 schrieb dwight elvey um 16:15:
HI
With a ring, you could use a token but that would require
a master to start things and restore the ring when it was broken.
...
Dwight
30 Jan
30 Jan
11:16 a.m.
What is the desired end result? What is the application? A simple
application may not need a "real" networking protocol. If "cluster"
means distributed processing, then you have a lot more than just
protocols to figure out.
Jim
Gerold Pauler wrote:
You don't need a ring to use token passing
protocols.
There are some token passing protocols implemented
on bus structures (IEEE-802.4 (token bus), PROFIBUS, ...)
Just my 2c
Gerold
Am Di, den 29.01.2008 schrieb dwight elvey um 16:15:
HI
With a ring, you could use a token but that would require
a master to start things and restore the ring when it was broken.
...
Dwight
11:50 a.m.
scheefj at netscape.net wrote:
What is the desired end result? What is the
application? A simple
application may not need a "real" networking protocol. If "cluster"
means distributed processing, then you have a lot more than just
protocols to figure out.
I am not sure exactly what Sellam wanted to do. I told
him I would help
out. If I can pass a message from one machine to another, I would be
happy. By no means does the system need to be TCP/IP or some other high
level protocol.
5:44 p.m.
Well, maybe a good place to start would be to gather requirements. ;-0
I've always been intrigued by the Ethernet solutions for the C64.
Having Ethernet is a great solution. Many of the solutions out there
only need a few I/O ports for interfacing, and with some onboard RAM you
have buffering that allows the host machine to do real work without
constantly polling the interface. (Well, you still poll the interface,
but you get some breathing room for real work.)
It's also really easy to send packets on an Ethernet. You don't have to
get fancy and do the full TCP/IP thing. (Nor should you on a C54.) The
physical link layer does the CRC for you, so you can do a simple
protocol on top of that.
Mike
29 Jan
29 Jan
5:37 a.m.
Hi Jim,
if you are using RS485 as the physical bus structure
you will be restricted to 32 units on the same bus.
You can use the description of multimaster protocols
like PROFIBUS (token passing) or CAN (priorities)
as a starting point, but you have to implement
your own peer to peer protocol on top of that.
Gerold
Am Di, den 29.01.2008 schrieb Jim Brain um 04:30:
Sellam wants to finish the 64 c64 cluster for the next
VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
Jim
9:57 a.m.
Since it's a C64, I assume that the ports are polled rather than
interrupt driven I/O? Flow control might be a problem if these
machines are doing other things at the same time.
I see two potential architectures....
The easiest is a ring with packet forwardings. Each machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
Next, there's a token ring where all of the outputs are connected to
all of the inputs, except perhaps not the input on the same machine.
For 64 machines you're going to need external electronics to clean up
the signals, since I doubt that a single output can drive 64 inputs.
The other potential problem is connecting inputs together. You are
going to need to prevent non-transmitting inputs from frying
themselves probably by tristating any input on a machine that doesn't
have the token. Even if you have them tristated you are going to want
current limiting protection so you don't blow out the ports when a
problem happens. I doubt that the C64 serial ports are specified to
survive having multiple transmitters on the same line.
For protocol, I'd go with a modified SLIP, since it's well specified,
small enough to implement on an 8 bit processor, includes appropriate
escape characters, the code is everywhere and it's easily modified.
We've used it for serial buses on spacecraft.
On Jan 28, 2008 7:30 PM, Jim Brain <brain at jbrain.com> wrote:
Sellam wants to finish the 64 c64 cluster for the next
VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
Jim
10:04 a.m.
You are
going to need to prevent non-transmitting inputs from frying
themselves probably by tristating any input on a machine that doesn't
have the token. Even if you have them tristated you are going to want
current limiting protection so you don't blow out the ports when a
problem happens. I doubt that the C64 serial ports are specified to
survive having multiple transmitters on the same line.
Brain not working this morning. I obviously mean outputs in the
paragraph above.
Eric
10:53 a.m.
Eric J Korpela wrote:
The easiest is a ring with packet forwardings. Each
machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
This was the approach I was leaning towards, as it takes care of the
fanout issues. But, for general purpose use, I was trying to think of a
way to have a node that is turned off have a "bypass". I thought of a
DPDT relay, but then I started to think of what would happen if the
relay closed/opened in the middle of a byte being transferred to the
machine turning off. How would I recover from that.
But, I agree, that solution offers the best hope.
For protocol, I'd go with a modified SLIP, since
it's well specified,
small enough to implement on an 8 bit processor, includes appropriate
escape characters, the code is everywhere and it's easily modified.
We've used it for serial buses on spacecraft.
Hmm, good idea.
30 Jan
30 Jan
12:39 p.m.
On Jan 29, 2008 10:53 AM, Jim Brain <brain at jbrain.com> wrote:
This was the approach I was leaning towards, as it
takes care of the
fanout issues. But, for general purpose use, I was trying to think of a
way to have a node that is turned off have a "bypass". I thought of a
DPDT relay, but then I started to think of what would happen if the
relay closed/opened in the middle of a byte being transferred to the
machine turning off. How would I recover from that.
I assume there's a way in software to reset the interface? Just reset
the input interface whenever you get a bad packet ID or source
address, a bad packet checksum or if packet times out. If you're
implementing something with a "resend packet after timeout" dropped
packets shouldn't be fatal.
Timeouts will have to be long because the packet will travel N hops
and the ACK will travel 64-N hops.
Eric
29 Jan
29 Jan
10:53 a.m.
Eric J Korpela wrote:
Since it's a C64, I assume that the ports are
polled rather than
interrupt driven I/O? Flow control might be a problem if these
machines are doing other things at the same time.
No, actually, the 6526 can generate an IRQ when the byte is delivered.
30 Jan
30 Jan
8:59 a.m.
Eric J Korpela wrote:
The easiest is a ring with packet forwardings. Each
machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
This is pretty much the only feasible solution IMO.
You have to ask yourself, "What is a cluster of C64 machines going to
do?" If it's a cluster, probably something like heavy lifting
(raytracing, calculating something, etc.). So latency isn't really an
issue because you don't need speed, just communication/synchronization
between machines.
What *is* this cluster going to do, anyway?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
9:04 a.m.
On Jan 30, 2008 8:59 AM, Jim Leonard <trixter at oldskool.org> wrote:
Eric J Korpela wrote:
You know, I forgot to say this earlier... but make sure to put this on
Slashdot when you get it working, it's the perfect /. story :) Just
don't host the site on a C64.
Imagine a Beowulf cluster of those... pouring hot grits down the C64's
pants... in Soviet Russia, C64's cluster YOU!
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
The easiest is a ring with packet forwardings.
Each machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
This is pretty much the only feasible solution IMO.
You have to ask yourself, "What is a cluster of C64 machines going to
do?" If it's a cluster, probably something like heavy lifting
(raytracing, calculating something, etc.). So latency isn't really an
issue because you don't need speed, just communication/synchronization
between machines.
What *is* this cluster going to do, anyway?
9:18 a.m.
On Wednesday 30 January 2008 17:04:32 John Floren wrote:
You know, I forgot to say this earlier... but make
sure to put this on
Slashdot when you get it working, it's the perfect /. story :) Just
don't host the site on a C64.
Imagine a Beowulf cluster of those... pouring hot grits down the C64's
pants... in Soviet Russia, C64's cluster YOU!
You forgot:
1) Get Commodore 64s
2) ???
3) Profit!
Gordon
9:39 a.m.
On Jan 30, 2008 9:18 AM, Gordon JC Pearce <gordonjcp at gjcp.net> wrote:
On Wednesday 30 January 2008 17:04:32 John Floren
wrote:
I, for one, welcome our new C64 overlords.
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
You know, I forgot to say this earlier... but
make sure to put this on
Slashdot when you get it working, it's the perfect /. story :) Just
don't host the site on a C64.
Imagine a Beowulf cluster of those... pouring hot grits down the C64's
pants... in Soviet Russia, C64's cluster YOU!
You forgot:
1) Get Commodore 64s
2) ???
3) Profit!
Gordon
1:13 p.m.
You forgot:
1) Get Commodore 64s
2) ???
3) Profit!
Gordon
I, for one, welcome our new C64 overlords. 
7:31 p.m.
2008/1/30, John Floren <slawmaster at gmail.com>:
On Jan 30, 2008 9:18 AM, Gordon JC Pearce
<gordonjcp at gjcp.net> wrote:
And, in this particular case; .. '64kb should be enough for anybody.'
On Wednesday 30 January 2008 17:04:32 John Floren
wrote:
I, for one, welcome our new C64 overlords.
You know, I forgot to say this earlier... but
make sure to put this on
Slashdot when you get it working, it's the perfect /. story :) Just
don't host the site on a C64.
Imagine a Beowulf cluster of those... pouring hot grits down the C64's
pants... in Soviet Russia, C64's cluster YOU!
You forgot:
1) Get Commodore 64s
2) ???
3) Profit!
Gordon
9:59 a.m.
On Jan 29, 2008, at 12:57 PM, Eric J Korpela wrote:
Next, there's a token ring where all of the
outputs are connected to
all of the inputs, except perhaps not the input on the same machine.
For 64 machines you're going to need external electronics to clean up
the signals, since I doubt that a single output can drive 64 inputs.
There are various chips available these days which are intended
for clock distribution applications that may help to address this
problem.
The other potential problem is connecting inputs
together. You are
going to need to prevent non-transmitting inputs from frying
themselves probably by tristating any input on a machine that doesn't
have the token. Even if you have them tristated you are going to want
current limiting protection so you don't blow out the ports when a
problem happens. I doubt that the C64 serial ports are specified to
survive having multiple transmitters on the same line.
...or use open-drain drivers with pullup resistors to achieve a
"wired-OR" configuration. Since each driver will only be able to
force a low, there will be no contention at that level. That'd be
trivial to do with a 2N7000 MOSFET or similar. The only thing to
watch out for (that I can think of) is that the gate capacitance of
the MOSFET will limit your switching speed. (Tony taught me that
many years ago, in the context of driving IR LEDs for comm
applications...thanks Tony!)
That circuit would amount to one (cheap, available by the bagful
on eBay) transistor for each node, and one pullup resistor for the
whole ring.
For protocol, I'd go with a modified SLIP, since
it's well specified,
small enough to implement on an 8 bit processor, includes appropriate
escape characters, the code is everywhere and it's easily modified.
We've used it for serial buses on spacecraft.
I like this idea. It also brings with it the possibility of
attaching another (non-C64) computer as a "test node" to access the
network.
-Dave
--
Dave McGuire
Port Charlotte, FL
2:28 p.m.
On Tue, 2008-01-29 at 09:57 -0800, Eric J Korpela wrote:
The easiest is a ring with packet forwardings. Each
machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
Many years ago I implemented a simple network using a single full-duplex
RS-232 port per node, connected in a simple ring.
The only features I remember at the moment were that each packet started
with a flag byte and destination address. In addition to the one-byte
latency required of the serial receive/transmit process, there was an
additional one-byte buffer so if the address byte matched then the
header byte was not passed on and the message would be absorbed by the
destination node.
Message bytes had to be contiguous, so a gap of more than (say) 1
character was deemed to indicate a fault. Because of the latency, the
forwarding node had the option of not passing on the last byte, so any
such packet would have one byte removed per node it passed through.
Also, if the entire packet was passed through but the CRC failed, the
last CRC byte wasn't passed on, initiating the message chomping process.
Oh happy memories!
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
3:49 p.m.
Eric J Korpela wrote:
The easiest is a ring with packet forwardings. Each
machine has its
output connected to one machine and its input connected to another.
This is probably the simplest hardware wise and software wise. It's
also the slowest. When a packet comes in, its destination address is
checked against the current machines address. If it doesn't match, it
is forwarded to the next machine. No collision detection is
necessary. One potential problem is that a packet with a bad address
can circulate forever unless you have a way of detecting it.
This reminds me of the network in the original XINU book.
4 Feb
4 Feb
9:50 a.m.
On 29/01/2008, Jim Brain <brain at jbrain.com> wrote:
Sellam wants to finish the 64 c64 cluster for the next
VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
This is probably not, by the sound of it, the sort of thing you're
after, but there are Ethernet interfaces for the C64 now...
http://www.dunkels.com/adam/tfe/
The Final Ethernet - C64 Ethernet Cartridge
Quote:
[[
The possibility of connecting the Commodore 64 to an Ethernet local
area network has been a collective dream in the Commodore community
for decades. A C64 Ethernet adapter would make it possible to connect
the C64 directly to the Internet, making it possible to download
software, transfer data to and from the C64, play network games over
the Internet; the possibilities are endless.
With our TFE cartridge (The Final Ethernet cartridge) this is now possible.
TFE - The Final Ethernet
The TFE cartridge is designed around Systor Vest AS' CS8900a-based
Embedded Ethernet board. The board is mounted on a circuit board which
contains a single 74LS139 chip that constitutes the glue logic between
the C64 and the Ethernet chip. More information including the full
schematics and pictures of the hardware can be found here.
]]
Since it's by Adam Dunkels, I'd guess it runs under his
ultra-ultra-lightweight multitasking OS for 8-bitters, Contiki.
http://www.sics.se/contiki/
--
Liam Proven ? Profile: http://www.linkedin.com/in/liamproven
Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419
AOL/AIM/iChat: liamproven at aol.com ? MSN/Messenger: lproven at hotmail.com
Yahoo: liamproven at yahoo.co.uk ? Skype: liamproven ? ICQ: 73187508
11:52 a.m.
Liam Proven wrote:
http://www.dunkels.com/adam/tfe/
The Final Ethernet - C64 Ethernet Cartridge
Yeah, there a couple. TFE (above), RR-NET, ETH64, and one from AU that
I forgot the name.
As noted, it's not really what I am looking for.
Jim
12:32 p.m.
Liam Proven wrote:
This is probably not, by the sound of it, the sort of
thing you're
after, but there are Ethernet interfaces for the C64 now...
Or, for giggles, something like Cambridge Ring could be interesting. Or maybe
Econet - although I drew up some stuff for a cluster of BBC micros a year or
so ago and came to the conclusion that Econet would be a bit inefficient, and
that doing everything byte-wide via the 6522 circuitry would be better.
Unfortunately all of my notes are stuck in a box back in the UK :(
cheers
Jules
6166
days inactive
6172
days old
31 comments
19 participants
participants (19)
-
brad＠heeltoe.com -
brain＠jbrain.com -
chd_1＠nktelco.net -
dkelvey＠hotmail.com -
fu3.org＠gmail.com -
gerold.pauler＠gmx.net -
gordonjcp＠gjcp.net -
jbglaw＠lug-owl.de -
jules.richardson99＠gmail.com -
korpela＠ssl.berkeley.edu -
ljw-cctech＠ljw.me.uk -
lproven＠gmail.com -
mbbrutman-cctalk＠brutman.com -
mcguire＠neurotica.com -
scheefj＠netscape.net -
slawmaster＠gmail.com -
spc＠conman.org -
spectre＠floodgap.com -
trixter＠oldskool.org