Streaming RealAudio From a Commodore 64
An anonymous reader submits: "This just came in on comp.sys.cbm and
I think it will be of general interest here at Slashdot as well. Two
Commodore hackers, Adam Dunkels and Peter Eliasson, have built an
Ethernet card for their C64 and have connected one to the
Internet. But they aren't 'just' running a TCP/IP stack and a web server on it - they are also
running a RealAudio server which streams audio from the C64's cassette
player and apparently, it sounds awful! They have the full source code
avaliable and pictures of the
C64 server."
Currently active TCP connections
A note for youngsters... The C64 is not a fancy new 64 bit machine, it is an 8 bit machine (vintage 1982) with 64Kbyte memory.
and you might hear the crackle of a flaming C64...
Some people see things as they are and say why. I see things that never were and say why not.
Then again, some people say "why not," get drunk, and and hook a piece of crap up to the internet.
$50 bucks to the first person that builds a C64 emulator out of legos that streams video of a coffeepot and runs BSD.
----------
I am an expert in electricity. My father held the chair of applied electricity at the state prision.
Well, I managed to mirror the front page before the machine went down (hopefully others can mirror my copy before my machine goes down!) http://inconnu.isu.edu/~ink/c64
The wheel is turning, but the hamster is dead.
I bet that ethernet card probably has more CPU power then the rest of the machine.
autopr0n is like, down and stuff.
C'mon now, Real Audio(TM) always sounds awful. This isn't news!
ôó
I don't even believe a Beuowolf cluster of these could survive serving streaming media to
Holy shit! This thing is still standing! I was able to get through with just two tries (the first time I just got the frameset). According to the docs they had put in quite a few optimizations to their TCP/IP stack to allow for a lot of connections (they said they encoded the state data in TCP sequence field, allowing them to have unlimited connections, or something like that)
:P
The thing is, they haven't got the optimization on port 6510, so if you try to go to the 'tcp status page' you'll overload it.
Building a C64 web server is impressive. Building one that can stand up to the Slashdot effect is, well, wow
autopr0n is like, down and stuff.
On the whole, lots of peripherals and expansion cards back then had ridiculous amounts of processing power. For example, the floppy drive usually used on the C64, the 1541, had a 6502 processor (a slightly older version of the 6510 used in the C64 itself). C64 facts from here. The floppy drive was connected to the machine with an insanely slow serial port, so it had to work more or less autonomously.
The silliest example of over-powerful peripherals has to be the General Sound card for the ZX Spectrum. The General Sound contains a 12 MHz Z80 and 128 K RAM, upgradable to 512. The Spectrum contains 48 or 128 K RAM (256 or 512 on some clones) and has a 3.5 MHz Z80 (7 MHz or more in some clones). In other words, the sound card (which is fully programmable) is more than 3 times as powerful as the machine it's connected to. General Sound info here.
For today, ponder the latest 3D graphics accelerator.
As one of the guys who made this, I must say that I am amazed to see how well our C64 server is handling the Slashdot-effect. With a little more than 50 comments, I still can load parts of the first page.
The web server that runs on port 80-84 actually implements a simple form of overload protection and during testing, we managed to serve 8000 pages over a period of 30 minutes. That makes 4 pages per second! Note that it is only the first page that is overload protected, so the other pages will still load very slow (if they will have a chance to load at all!).
The real-time streaming audio server is running on the same machine as the web server so nobody will probably have a chance to hear the audio stream.
Furthermore, the headline is wrong - we are not streaming RealAudio. We are streaming audio using the open RTSP/RTP formats that RealPlayer and other players can handle. The RealAudio file format is secret so we would probably have been sued if we had been streaming that.
Finally, here is Google's cache of our newsgroup announcement.
Maybe Jon Katz's friend, Junis can now send us live streaming audio from Afghanistan using his Commodore! That is, if he can spare the bandwidth and disk space that he uses to download all those DivX ;-) movies.
They didn't they implemented a version of the standard RTSP/RTP protocal. This is an open standard similar to TCP/IP standard. It just happens to be the standard that Real Player uses for its protocal.
Well what the fuck did you do? Sat on your ass and read /.? Yeah, that's much more impressive.
sic transit gloria mundi
Is it just me or does that little C64 perform better than a NT server running IIS?
I'm sure it will stay up for longer as well...
Let's count the security holes...
This is really funny!
Then again: The OS on my mobile phone is more reliable than NT.
Oh, ok, we are talking about the C64 right? Wow, it's smaller than a NT server! Oops, here I go again.
"I used to have that really cool,funny sig
It has now been four and a half hours since this appeared on the front page, and our C64 server is still up and running.
/index.html page and only 1% have been for the RealPlayer description file /c64.ram.
I was just able to reach the access statistics page. There has been a total of 32000 accesses (of which 8000 came before the Slashdot attack). 25% of the accesses have been for the
24000 hits in 4.5 hours, thats nearly 1.5 hits per second.
Who's to say that their ingenuity wasn't spent doing something worthwhile? They had a blast, I bet, they overcame technical problems, and they learned a lot. And, they furthered the knowledge and realm of possiblility. (Who would have thought that a C=64 could handle a /. load?!?)
Now, if you were talking about the millions of dollars that goes into sports every year that could have been going to something worthwhile, I would agree with you.
Tom
Well if you want to cook a C64, there is a BASIC command that may do it:
WARNING: Use of this is at your own risk! May destroy hardware! Not recommended for any machine you'd like to keep! I WILL NOT BE HELD LIABLE FOR ANY DAMAGE WHATSOEVER
POKE 53270, PEEK(53270) OR 32
I did it and I could feel heat coming up from the keyboard and a smell like thermal paste overheating or something.
I turned it off very quickly and it did survive.
It was responsive and with a normal display right until I cut the power.
Some C64 docs say bit 5 of register 53270 is the reset bit for the VIC controller.
Some just say, ominously:
"ALWAYS SET THIS BIT TO 0!"
Why a reset bit would cause an overheat is beyond me. Anyone have a clue? I'd really like to know what is so bad about setting that bit. I was hoping it would just be a reset bit.
Just because it CAN be done, doesn't mean it should!
This is a cool project. /. should add a new category called, "Because You Can." You see, there are a lot of wicked projects that we cover here, but they're not so much funny as, "This is totally sweet." (e.g. linux on ____, webserver on _____, and now of course, real-audio streaming on _____).
Invariably when we cover these, you get a few responses like this: "Why would you ever want to do this... blah blah."
Invariably, the response is: "Because you can."
The next step, of course, after creating such a category, is to make sure it's mirrored well before it's posted. (*wistful look*)
Now, I haven't checked whether this story is a hoax or not, but if it is, then it should be in the "Funny" category. Otherwise, consider this post as a call for a new category called, "Because you can!"