Ethernet, TCP/IP, web server, and real-time streaming audio on a C64
Adam Dunkels
elsewhere about the possibility of connecting a standard Commodore 64
to an Ethernet network. There have even been a few attempts at
designing Ethernet adapters for the C64. Those have not amounted much
other than vigorous discussions, however - no working hardware has
been produced.
In the discussions, different people have viewed the idea of Ethernet
for the C64 with different amounts of optimism. Some have proclaimed
that connecting a C64 to an Ethernet is impossible and totally out of
the question, whereas others have thought it to be quite simple to
realize. Still, nobody has produced any hard facts to back up any of
their their claims.
This is no longer the case.
We are proud to announce what we believe to be the world's first
Commodore 64 Ethernet adapter - TFE - The Final Ethernet[*]. The TFE
card plugs into the cartridge expansion port and does not require any
extra hardware such as SuperCPU accelerators or RAM expansions.
We have a TFE-equipped C64 connected to the global Internet, and it is
of course running a TCP/IP stack and the obligatory web server.
But we took the idea of running our C64 as an Internet server one step
further. Our C64 web server not only serves web pages, but is also
running a real-time audio streaming server. The audio server streams
directly from a tape in a standard Datasette cassette player connected
to the C64. The server has been tested with RealPlayer version 8, but
other clients may work as well. We are currently playing remixes of
famous C64 tunes from games such as Last Ninja, Delta and others
(music taken from http://remix.kwed.org/).
Because the cassette port only is capable of sampling 1-bit at a time,
the quality of the audio is awfully bad. To reduce the load on the C64
server, we only allow one listener at a time and each listener is
limited to listen for about 30 seconds. The server is located in
Stockholm, Sweden, so Europeans might have a slightly better chance of
getting the packets through.
The C64 web- and real-time streaming server can be reached at
http://tfe.c64.org/ and more information about this, including
pictures and schematics of the hardware as well as all source code for
the software can be found at http://dunkels.com/adam/tfe/.
We who have done this are Peter Eliasson (hardware) and Adam Dunkels
(software).
Many thanks go to Mikael Nehlsen for providing us with the C64 that
runs as the server, the Elab at the Swedish Royal Institute of
Technology for making it possible for us to manufacture the two
prototype cards, and to the Swedish Institute of Computer Science for
providing the Internet connection and bandwidth for our C64 server.
*** The Hardware ***
The TFE cartridge plugs into the cartridge expansion port and consists
of a custom made printed circuit board and the CS8900a based embedded
Ethernet board from Systor Vest AS [http://www.embeddedethernet.com/].
The circuit board is equipped with a single 74LS139 decoder and one
led indicating access to the CS8900a Ethernet chip.
We have manufactured two prototype boards at a cost of approximately
$100 a piece. The cost is dominated by the Embedded Ethernet board
that costs $70. Currently, we don't have any plans to start producing
TFE cards, but others are welcome to use our schematics as long as
credit is given to the creators.
Pictures of the TFE cartridge in action can be found at
http://dunkels.com/adam/tfe/pictures.html. Full schematics of the
hardware is available at http://dunkels.com/adam/tfe/hardware.html.
*** The Software ***
The TCP/IP stack and the web server is of course the uIP stack
[http://dunkels.com/adam/uip/], which also is used to run the C64 web
server at http://c64.cc65.org/. The HTTP server software at
http://tfe.c64.org/ has been enhanced with a special kind of TCP/HTTP
optimization in order to prevent overload. Note that this optimization
only is used for the front page - the other pages are served by a
regular HTTP daemon and will load slower than the front page.
The optimized version of the HTTP server runs on TCP ports 80-85 and
because it makes certain assumptions of the properties of the TCP
implementation of the web client, it might fail for some people. If
so, try regular web server running on port 6510 which is slower but
will work with all clients: http://tfe.c64.org:6510/index2.html
The streaming audio server is a very tiny implementation of the two
protocols RTSP (Real-Time Streaming Protocol) and RTP (Real-Time
Protocol). The sampled audio is sent out as 8-bit 8000 Hz PCMU data in
RTP datagrams over UDP. To reduce CPU processing overhead, the UDP
datagrams are sent with the checksum turned off. The RTSP
implementation has not been widely tested and might fail to work
correctly with other clients than RealPlayer version 8.
The source code for all the software is available on the web site:
http://dunkels.com/adam/tfe/software.html
*** Flipping the Tape ***
During the testing of the C64 server we quickly found out that having
a server running 24/7 would be impossible because the cassette tape
would have to be flipped every 45 minutes.
So how do we manage to have a server running 24/7? Well, we are
cheating a little - we are using a kind of tape that is used to
connect portable CD-players with older car stereos. The "tape" is
equipped an audio input coord which we connect to the sound card of a
nearby PC. The PC plays the MP3 music, fooling the C64 into believing
that it samples an ordinary tape.
*** Conclusions and Future Work ***
We have shown that Ethernet connectivity for the Commodore 64 indeed
is possible and that a TFE-equipped but otherwise unexpanded Commodore
64 is capable of not only running a web server, but also stream
real-time audio over the Internet.
We plan on developing software for transfering disk images to and from
the C64 over the network, and have vague plans on writing a simple web
browser and email client for the C64.
The cost of the hardware could be cut either by using another Ethernet
controller chip, or by a custom design that doesn't use the Embedded
Ethernet board, but the Ethernet chip directly.
Adam Dunkels and Peter Eliasson
April 12 2002, Stockholm, Sweden.
Footnotes:
[*] The name is obviously a pun on the name of The Final Cartridge,
which despite its name was produced in at least three versions.
--
Adam Dunkels <ad...@dunkels.net> (Spambait)
http://dunkels.com/adam/
Six of DLoC
12 Apr 2002:
That's simply amazing. Kudos, eh... Any chance of a model with a
cartridge passthru?
--
Six of DLoC
Cameron Kaiser
>That's simply amazing. Kudos, eh... Any chance of a model with a
>cartridge passthru?
My thoughts exactly.
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
Robert Bernardo
board, which holds several carts at the same time, be used in lieu
of a cartridge pass-thru?
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
Frogbert
> Six of DLoC <s...@dloc.ath.cx> writes:
>
> >>http://tfe.c64.org/
>
> >That's simply amazing. Kudos, eh... Any chance of a model with a
> >cartridge passthru?
>
> My thoughts exactly.
*wipes tear from eye* Its like some sort of dream come true, its
just.... *breaks into tears of joy* sorry i cant go on
bud
Congratulations Adam and Peter!
salaam,
dowcom
--
http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE
DOShead Credo:
a) Try it! It might work.
b) GOTO a).
Adam Dunkels
Saturday 13 April 2002 07.56, Robert Bernardo wrote in comp.sys.cbm:
> Congratulations on the achievement! Can a cartridge adapter
> board, which holds several carts at the same time, be used in lieu
> of a cartridge pass-thru?
In principle, I guess there are no problems in incorporating either a
cartridge pass-through on the TFE or using it on a cartridge board. The
problem is with the address space on which the CS8900a Ethernet chip is
mapped. Currently, is resides on $de00-$deff in identical copies every 16
bytes (similar to how the VIC and SIDs are mirrored every 64 and 32 bytes,
respectively). This would class with many cartridges such as the TFC and
the AR.
In order to have multiple cartridges, the TFE would have to be extended
with some address decoding logic that would restrict the TFE to an area
such as $de20-$de2f or $dfe0-$dfef. I believe there is a list of standard
mappings for various cartridges that would be adhered to, in such a case.
When we started thinking about the TFE, we originally envisioned a device
that would plug into the user port, thus leaving the cartridge port open
for TFCs, ARs, REUs and similar stuff. But because of the limitations in
i/o signals on the user port, we skipped the idea. (We actually had some
more or less serious plans on using CIA timers in place of address signals,
but the software for handling it would have been very complex.)
/adam