A Twitter Client For the Commodore 64 177
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."
Re:FW (Score:2, Interesting)
Re:Much Faster Floppy Drive for the C64 (Score:4, Interesting)
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.
Re:Software really has yet to catch up to hardware (Score:5, Interesting)
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 ;).
Not necessarily so funny (Score:2, Interesting)
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.
Re:Speccy vs. C64 slugfest - start here! (Score:4, Interesting)
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!
Re:Software really has yet to catch up to hardware (Score:0, Interesting)
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.
Re:Software really has yet to catch up to hardware (Score:3, Interesting)
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!
Define "more powerful processor" (Score:3, Interesting)
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.
Re:Wrong why? (Score:4, Interesting)
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/ [1541ultimate.net]
Re:Much Faster Floppy Drive for the C64 (Score:3, Interesting)
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 [wikipedia.org]
Re:Not necessarily so funny (Score:4, Interesting)
On the contrary, I've used POV, probably the initial release and on that same Atari. Hell, I think I've even used DKBTrace. I've written my own GUI-less raytracers as well. It's kind of hard to do a magazine layout with POV, or design packaging, or create a logo, or composite effects into video. I've moved on to professional tools and will never look back unless I have some very specific need that only POV can fill. For procedural graphics and scientific visualization, it can be great. It's wonderful for hobbyists on a budget, or those in love with raytracing and willing to get their hands dirty, or those who want to learn more about raytracing in general. For work in a production environment? Get real. It continues to make advances, but it's still ten years behind the curve, and completely unwieldy for most CGI tasks. I have a friend who loves POV, she does all her game graphics with it. It shows.
CLI video editing? You must be on the moon. You're certainly not an editor, unless your idea of editing is ripping DVDs. I cut my editing teeth on 3/4" U-matic tape. Then I moved up to a CMX, which is a computerized analog linear editing system with a text interface and dedicated console and computer controlled VTRs. Then I moved up to a traditional, computerized, timeline-based NLE with analog capture/playback, and then eventually digital I/O. Today I use a next-generation NLE which is much faster and much more efficient than any form of editing before it or currently available from other vendors. Without those advances, I'd still be working on the first film. When a film has 1000+ edits, with each of those edits being tweaked up to seven or eight times, and each of those shots selected from twenty times as much logged footage, you don't want to screw around. What I do today, and what I do to stay competitive, would be virtually impossible and utterly impractical without a GUI. Film is a visual medium. It makes no sense not to edit it in a visually way. Would you edit audio without speakers or ears? I'm sure SoX is a fine tool, probably great in a proper tool chain, but you're on goofy pills if you think it's any kind of substitute for Pro Tools. I doubt you'll find a single musician that uses SoX for anything but purely utilitarian purposes (as opposed to creative ones), and even then, I'm doubtful.