Slashdot Mirror
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."
Well, this is what you would've seen if you were one of the first 10 people to click the link... poor lil' webserver...
Real-time streaming audio from the C64
This C64 server is not only running a web server, but is also running
a very simplistic RTSP/RTP (Real-Time Streaming Protocol/Real-Time
Protocol) server that is compatible with RealPlayer
version 8. This makes it possible to send real-time streaming audio
over the Internet directly from the Commodore 64.
The cassette port on the C64 is capable of sampling 1-bit samples at a
maximum rate of approximately 8000 Hz. We are sampling 1-bit audio
from the cassette player and sending it out over the Internet using
the TFE Ethernet cartridge. To reduce the load on the C64, we only
allow one listener to listen at a time and only for about 20 seconds.
Listen
In order to listen, you'll need to have the free RealPlayer 8 Basic (click on the "RealPlayer 8
Basic" link at the bottom left of the page). While the streaming audio
server might work with other players, we haven't tested it with
anything but RealPlayer 8 Basic.
When RealPlayer is installed, click here. If
RealPlayer says that it is experiencing network problems, this is
because someone else is already listening. Beware! It sounds
terrible.
Playlist
We are playing remixes of famous C64 SID music taken from the
faboulous C64 mp3 remix site remix.kwed.org. Because of the bad sound quality of
the real-time audio stream, it is impossible to tell which tunes we are
playing.
-- 'intellectual property' is oxymoronic
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.
Er, I dunno what system you're on, but if it's a PC, no, it uses the same head technology. Commodore was actually the first to mass-market a system based on that type of head & disk format, older systems used a completely different system which packed far less data onto the same space (hence those god-awful 8" floppies).
There are C64 floppy reader/writer for PCs with 5.25" floppy drives. Granted they're pretty hard to get ahold of these days, but... you could transfer stuff there with one, 180K at a time. Or was that 170K?
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.
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.
http://www.xemu.org/mirrors/adam/
Acutally, it's not a problem, all you need is a 32K ram expansion and an RS-232 interface. The VIC-20 has got just as much CPU power as the C64, and it runs an earlier version of the same operating system, so a port is actually possible.
READY.
#
Uhmmm, one of these dudes wrote the uIP TCP/IP stack.
Now, if you'd said lunix you might have been right. It's a nice little Un*x clone specifically written for the 8-bit Commodores.
Insert witty sig about inserting witty sig here, here.
No. It's a C-64 v2. Later C-64s came in a C-128-like case, with a modified chipset. They used the 85xx series of CMOS chips, like the C-128. Most important difference was in the voltages used to drive them. I believe the 6581 SID used a +12 volt line to drive its oscillators, whereas the 8581 used +5 volt.
I may be wrong, but I do remember that the 85xx series could not be used in 65xx slots. That was a bastard when my 8581 died in my C-128, as that part was produced in such slight quantities that I could only get a 6581 as a replacement, which was no use. I not only lost sound, but I lost my random number generator as well (the RND function was seeded from the white noise oscillator in some programs).
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
> Commodore was actually the first to mass-market
> a system based on that type of head & disk format
Bzzt! Wrong. As far as I know, IBM was, but not Commodore. While its true both systems used 5.25" double-density disks, IBM PC disks are MFM encoded; Commdore's disks are GCR encoded from the 4040 (late 70s) until the release of the 1571 (late 80s). The 1571 added an MFM encoding mode and double-sided capability in order to be compatible with CP/M disks for the CP/M mode of the C128. That was the first drive able to read PC floppies, although extra hacking was required.
The 4040 (cum 1530, 1540, 1541) disk format that we're all familiar with held 170K -- actually, 169984 bytes of data after formatting, arranged in 664 blocks of 256 bytes.
Do daemons dream of electric sleep()?