Slashdot Mirror
A Twitter Client For the Commodore 64
An anonymous reader writes "Johan Van den Brande has developed a Twitter client for the Commodore 64, allowing 140-character messages to be posted directly from this TV-connected 1982 home computer. This YouTube video shows how the Twitter client is — slowly! — loaded from a 5.25" floppy disk, how the latest Twitter messages are downloaded and shown on the TV screen, and how this tweet is posted. All that is needed is a C64, a TV, and a C64 Ethernet card. The Twitter client is implemented with the Contiki operating system, which otherwise is used for connecting tiny embedded systems to the Internet."
Maybe a Commodore 64's 800 baud modem can handle the size of a single tweet transmission if you strip out the HTML.
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
The drives your talking about are probably the 8050 quad density drive series (and the SFD-1001 - which was for the C64)) - 1 megabyte as I recall. Two problems with them - a) they were hard to buy and b) quad density disks are impossible to find (you can't even use pc high density disks with them). Still the one I saw demo'd was incredibly quick.
1541 used a 300 baud serial interface to the pc itself. In non burst mode programs took forever and a day to load or save - it wasn't entirely uncommon for a 15-20 minute load time.
Still it was light years faster than tape (which was less than 50 baud).
Yup - C64 was a complete hack, but you couldn't beat it for the price. For about 800-900 dollars you could have the PC and the 1541, where Apple ][ of the same vintage was 1500$+ with no accessories at all.
Not all companies back then developed directly on the C64 either.
There were dev tools for the PC for the C64 for example.
I don't think its cheating to use a bigger PC to develop a complex app for a smaller machine ;).
Any success in developing resource-efficient software is to be celebrated, IMHO. There is far too much of a trend these days of writing bloated, horribly inefficient crap, simply because in hardware terms we can get away with it.
The Windows refugees desperately need to stop being listened to. All they care about is superficial usability. They don't care about design quality, code quality, robustness, security, or resource (RAM/cpu/power) efficiency. The only important thing is that whatever they want to do is, "easy," and also, preferably, that it includes pretty lights.
We need software that is resource efficient, and well designed. We need it because we're not always in scenarios where we've got access to a 4 Ghz processor, 32 odd GB of ram, and a terrabyte hard drive. Such machines tend to be expensive, and also to require a lot of power.
If the world underwent some sort of disaster next week which included a loss of mains power, the 4 Ghz desktops with KDE wouldn't be what people would be running, if they were using a computer at all; because they wouldn't have the electricity to be able to waste it on such hardware. It'd be iPods or other power-efficient ARM-based machines running NetBSD or minimalist Linux configurations, with something like Blackbox as a window manager.
There's a reason why I have Ratpoison as a window manager for daily use, despite having a gigabyte of ram at my disposal. It's because I've used a C64 with a tape drive, and a portable IBM XT with a 2400 baud modem, and I'm thus able to recognise a graphical user interface for exactly what it really is.
A convenience. Not a necessity. There's a very big difference.
The C64 vs. Spectrum slugfests on usenet are legendary, and used to happen once or twice a year. And they were always hilarious! I mean, we're all grown ups with the wit of a child, and nobody is stupid there - it's really done for the fun of it. It does get deeply technical at times, but the humor is always present.
Slashdot has nothing on those long-winded usenet threads where we cudgel each other good!
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Both running in VirtualBox. Both have been tweaked to start with as little as possible without special hardware tools.
Win XP:
30 second boot time
88.9 Megs Loaded from HD
16 processes
95.5 Megs Ram Used
HD footprint: 6.23gig
----------------------
Ubuntu 9.04:
42 second boot time
137.4 Megs Loaded from HD
106 processes
93 Megs Ram Used
HD Footprint: 2.80gig
Of course, you can compile your own stripped down kernel and use a desktop environment that rivals Windows 3.1 for "XP beating" speed, but it's amazing how wrong people's assumptions about Linux really are.
"When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
There's obviously a lot of truth to the ease of programming using high level tools, and standing on other's shoulders, but back in the day we made do with what we had. I used to work for Acorn Computers (UK) back in 1982, and was one half of the team that implemented ISO Pascal for the 6502-based BBC Micro...
The project was divided into two halves (shipped on two 16K EPROMS), one half being a stack-based virtual instruction set for the compiler to target (to get reasonable code density), Pascal run-time libraries (I/O, floating point, heap, etc), a decent screen editor including regex search/replace etc, a command line interpreter... this all written in 6502 assembler developed on a BBC micro using it's own BBC BASIC inline assember... and the other half being the Pascal compiler which was written in Pascal and self-compiled. We did bootstrap the compiler using an existing one on another (equally slow!) system, but as soon as it could self-compile we moved all development to the BBC micro.
It's really not so bad to bootstrap yourself up from assembler to decent development tools. Write a very minimal C/whatever compiler in assembler, then write a better one in that language/etc, and repeat!
Try writing a useful program on one of those bit-slice efforts, though, and you would quickly run into a brick wall. Very limited microcode, no assembly language, no developer tools of any kind. The point about the 6502, the Z80, and even the 8088, was that you could write general purpose programs to run on them, execute them and debug them.
By the time general purpose CPUs were powerful enough to run the floppy, control the display and handle the I/O devices at the same time, it no longer made sense to do so because it was more cost effective (in terms of performance) to hand off the functions to dedicated peripherals even in microcomputers.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
If it makes you feel any better I've been loading it off of an SDHC card that is inside of a cartridge that emulates a 1541 disk drive.
http://www.1541ultimate.net/
Lots of people know more about it than I do but the 1541 is basically a computer, IIRC it's about as powerful as the C64 itself. You could write loader code for both the drive and computer and achieve far more speed than letting the system just go forth and handle things for you. See also Epyx Fastload
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"