June 2007 Archives

Why I won't be getting an iPhone - Just Yet?

| | | |

Everyone else is commenting on the new iPhone before it's release, so why can't I? My two cents is that I won't be camping out at the Apple Store for an iPhone this evening. Yes, the price seems high, but in reality its not. If you price other smartphones, it becomes obvious that without the common provider subsidy, smarpthpones are expensive. An unlocked Palm Treo 680 goes for $399 retail. The Nokia N95, will setup you back a whopping $749. Spending $499 or $599 seems average all of a sudden. I purchased an unlocked, 'used' and discontinued Palm Tero 650 in January via eBay and it cost me around $160. Sure, I could have purchased a new Palm Treo 680 for $199, but that would have stuck me with a commitment to a different provider.

Ay, there's the rub, I don't want to switch providers. I'm quite happy with T-Mobile. I spent hell on earth for many years with Sprint. A small example, no matter how many times I corrected them, they couldn't get the spelling of my last name correct. More than once I had half a mind to skip paying. If they complain, I would have said, "Sorry but nobody by that name resides at this address." Strike one against Sprint.

Most of my time with Sprint was spent before the ability to keep one's cell phone number while switching networks, so I just learned to limit my contact with their 'customer service' representatives as much as I could. When I moved back to Chicago from the San Francisco Bay Area I had a chance to start anew and took it - I also learned how horrible Sprint's coverage area was outside of a metropolitan area while driving the moving van. Strike Two!

I did a little research and chose T-Mobile. The biggest reason for T-Mobile at the time was the fact that its uses GSM, which is the worldwide standard, for its phone network. For me, the logic played out like this: GSM is a more widely adapted technology and given the fact that I'll be traveling abroad more - my wife-to-be is Irish, her and her family emigrated to the States when she was 5 - and given the horribly out-dated experience I had using a long distance phone card the first time I meet her family - thanks to Sprint, strike three, your out - it seemed the right thing to do. In fact, it has been the right thing, while I don't make a lot of calls, let alone calls while abroad, I've found that text messaging, both back to the States and with 'the locals' is the quick, easy and relatively cheap way to communicate, keeping everyone on the same page when needed.

Yeah, I know AT&T is GSM, but that's only one factor. Another, as you can guess by the knocking on Sprint, is service, both the network and the customer kind. I have very little patience for what passes as customer service these days; I do not suffer fools gladly - I can admit that I'd make a poor customer service representative myself, but that's a different set of issues. I'm happy with T-Mobile. I don't tend to communicate directly with them much, but when I do I can't complain. In two plus years with them, I've only had one issue with a rep offering me bad advice, but it was quickly corrected when I brought the problem up with another rep. I can't say I'm itching to move to a different provided for 'better' customer service.

While in theory AT&T's voice service is the same network technology, thus the same coverage, I'm a little concerned by David Pogue's note that "in a Consumer Reports study, AT&T's signal ranked either last or second to last in 19 out of 20 major cities" and that his own tests with the iPhone in five different states "bear this out." Not a good sign. A worst sign is the fact that the first version of the iPhone is using the EDGE network for data, instead of and as many others wish to see, HSPA or the like. I think Pouge speaks for many gadget--heads when he says this "drawback may be deal-killers for some people."

Indeed, my Treo 650 and the Motorola v600 I originally had with T-Mobile use GPRS for data, which is slower than EDGE, but given the grandfathered in t-zones data plan I have, $4.99 for unlimited data, means I won't be jumping ship for something slightly faster. Moreover, GPRS is just fine for the Blazer web browser accessing WAP enabled websites or using Chatter to sync IMAP for mostly text based email. I'm sure trying to access 'rich media' with Mail or Safari on the iPhone with a stopgap data network would indeed be "excruciatingly slow. You almost ache for a dial-up modem."

In other words, I like my service provider; I like my service plan and I'm happy with the voice/data network and customer service I receive. While I'm not using a T-Mobile phone, having dumped the Motorola v600 for said Treo 650, I'm content with the phone itself, its large software library and the gigabytes of advice floating around on the 'net. Its not just about 'the phone' its about the phone, the network and the customer service.

Now, if I got my hands on an unlocked iPhone...

Apple Hacking For Fun and Profit

| 31 Comments | 1 TrackBack
| | | |

The Preface

I'm sure some one will read this post and comment, well that's not innovative, using an Apple II as a 'dumb' terminal to a Mac. My answer is that this solution is not meant to be original or even 'modern'. The steps outline here is about practicality - with perhaps a sense of style, long standing appreciation for Apple hardware and fun at discovering or rediscovering some useful computing setups. There are of course plenty of wild and crazy projects people have undertaken with 'out-dated' hardware, but in the end are those projects 'useful'? Setting up an Apple II as a terminal might not be useful to everyone, but what I've outlined below is an evolution of a project I've been thinking about from sometime, and the obvious usefulness in a working environment just finally caught up with me.

One other note, I've had succeeded in setting up an un-enhanced Apple IIe and an Apple IIc in the manner described below. In theory any Apple II should work, but I make no promises that the process is the same, or is even possible on all compatible Apple IIs.

The Necessity
It's a well-regarded 'fact' that electronic devices are outdated even before the packaging has been completely removed. This fact might explain why the Apple II computing platform's 30th birthday this month has come with little fanfare (or perhaps everyone is just overly stimulated waiting for the iPhone?) Yet, the Apple II family of computers can be just as useful today even if they are no longer considered 'state-of-the-art'.

The first Apple II computer, the successor to Apple's first computer, was introduced to the world in April of 1977, yet it didn't go on sale until June, hence its June 5th birthday. The platform's openness and ubiquity help carry it even in today's world of 'modern' computing platforms. For example, take a look at my current office setup, one Mac mini, one Apple IIc. If you look closely enough, you'll see that IIc is more than decoration, it is running and is in fact used everyday.

A nice, functional workspace

For those new to this blog, I work as a web developer for zoomshare. In this capacity I can have any number of different applications running at the same time. Usual suspects include Text Wrangler, Safari, Internet Explorer (versions 6 and 7 via Parallels), Firefox, Terminal, iTunes and Mail. With those applications and more, depending on what I'm working on, my screen can get pretty cluttered, pretty fast. Over the years there have been many 'solutions' to this issue, bigger screen, multi-screen or virtual screen (a.k.a. virtual desktops) setups.

Bigger screens and multi-screen setups are fancy (and in vogue these days), but on the Mac side of things you have to plunk down serious money, not something many budget conscious businesses will spend out of hand. Worst yet these options don't really solve the problem but lessen it but trying to add more 'real estate' to the computing desktop. Virtual desktops are a better solution since they skip the hardware display's limit all together. With virtual desktops any number of desktop workspaces can be created. But until Spaces in OS X 10.5 is released, its not supported by default on the Mac platform and third party apps can get a bit messy, with dialog boxes and toolbars getting 'lost' from their application's main window.

So virtual desktops is workable, but not perfect. What I need is the ability to off-load some of windows, ones that need to be visible even for a quick glance, as needed, an IRC conversation or the output of a running web process, for example. Taking a looking at the applications I depend on I see the beginnings of an idea. Terminal is an interesting application, a piece of software that's mimicking what use to be a hardware function. Why can't it be a hardware function again or at least why can't it be running on a dedicated piece of cheap, reliable hardware? Enter the Apple II platform and the nice, compact IIc.

The Hardware
While the IIc is a 'closed' system, unlike other Apple IIs it does include two built in serial ports, one for a printer and one for a modem. A compatible Super Serial Card drives both of these serial ports. The Super Serial Card, introduced in 1981, became the main stay of serial cards from Apple since it replaced the need for two individual cards for a printer and modem. Another eccentricity of the IIc is the fact that instead of a standard RS-232 port the two serial ports are 5-pin DIN connectors, which will thus require an adaptor cable from the DIN connector to the more standard, 9 pin, RS-232 connector.

5 pin DIN to RS-232

RS-232 Null Modem

Keyspan USB to RS-232

On the Mac side of things, the mini includes a collection of Firewire and USB ports. Since USB is just a glorified serial port a USB to RS-232 adaptor does the trick for the task at hand. All that remains is to connect everything, plugging in the DIN cable into the IIc's modem port the USB into a free USB port on the mini and the two RS-232 adaptor ends via a null modem, which is simply a RS-232 cable wherein the transmit and receive lines are crossed.

The Software
First step is to install the drivers on the mini for the USB-Serial adaptor. At the time I started this project, I had to go fishing on Keyspan's website for Intel compiled drivers, so if at first you don't succeed try, try again. Once the driver is installed I opened up Terminal a did the following:

$ cd /dev
$ ls tty.*

The tty.KeySerial1 and/or tty.USA19H5d1P1.1 shows I've successfully completed the first step.

If you happen to have an old copy of a telecommunication software for the Apple II that supports vt100 terminal emulation then your all set software-wise. If not, the next step is to download a copy of Virtual II for the mini, which is what I had to do.

Virtual II, by Gerard Putter, emulates an Apple ][, ][+ or //e on the Mac OS X platform. Better yet the download also includes A2V2 (a Mac program) and ADT (Apple II program) that allows for the transferring of disk images of Apple II software to and from via the newly created serial connection. Moreover, the documentation for setting up a serial connection and transferring disk images that's supplied with A2V2 is fantastic, I relied on it quite heavily while first researching and attempting this little project.

After downloading A2V2 I first needed to follow the documentation to transfer a copy of ADT, Apple Disk Transfer, software to the Apple II. It also makes a nice first test to verify the serial connection. With ADT up the next item on the agenda is to download and transfer a communication program to the IIc. I tried a number of different software titles, even purchased PROTerm 3 off of eBay, but after a bit of fits and starts with different titles, I've finally settled on Modem.MGR.

Modem.MGR is solid communications program that will run on the II+, IIe, IIc and IIgs and, obviously, supports a wide-range of hardware configurations. It supports a number of different functions, including vt100 (actually vt220) emulation and is available for DOS 3.3 and ProDOS. Best of all Modem.MGR is Freeware, so I don't have to worry about infringing on any old (but still enforceable) copyrights. All that flexibility comes at a cost given the limitations of the Apple II platform in terms of memory, which means a bit of upfront work to configure Modem.MGR for the Apple II in question.

With the disk transfer completed I had three floppies hanging around for Modem.MGR a Installation, Utilities and Work disk. The first step towards getting Modem.MGR up and running is to insert and boot up the Installation disk. When ready Modem.MGR will ask for the Work disk, what will be the main application disk, to be installed and read from. Once back to the Installation disk its time to configure the app. For the IIc this means selecting the Apple // 80 column (menu option 2) video driver and selecting the Non-smart modem (menu option 10) option for the modem. One can review the selections if needed, but really the next step is to save the configuration back onto the Work disk.

When Modem.MGR is booted and loaded from the Work disk it displays a listing of commands that can be accessed by first pressing the 'ESC' key and then pressing the letter (on the left-hand side of the colon) that corresponds to the command one wishes to enter. At any time, if I'm not sure which letter/command combo I wish to use I can simply press the 'ESC' key and Shift-? to redisplay the complete list.

The first two steps in Modem.MGR is to set the modem baud rate, i.e. the connection speed and the parity for the data connection, when to stop and verify bits sent across the connection. The connection speed, ESC-M, can be set to one's liking, up to 19200 baud. I've settled at 1200 baud, because I like the retro feel of working at that speed and, to be perfectly honest, I don't think the IIc's display can keep up with the higher speed. The parity, ESC-J, is 8+1+None.

Next stop in Modem.MGR is to startup the vt220 terminal emulation. The key combination for this is ESC-: (that's a colon if your not sure) and then 'V' for loading the vt220 terminal emulation module.

Within everything ready on the IIc side of things, its time to take a look at the mini; in theory all that needs to be done to enable the mini is to get ttys to run getty, i.e. initialize the relevant serial port and invoke the login ability at the command-line. To enable getty requires the following line in the ttys configuration file at /etc/ttys:

tty.KeySerial1 "/usr/libexec/getty std.1200" vt100 on local secure

The first line item is the USB adaptor; the second line item is the getty app location along with the terminal type and baud rate. The last set of items include additional information about the terminal, what type of emulation, if it's a local connection and if its secured such as to allow root logins from. With a reboot to reload ttys all will be golden, a login prompt will appear on the IIc and one is off to the races, happy and carefree.

Yet something seems off. I've tried this numerous times, but I always end up with the same result, nothing, nada, zilch. As far as I can tell there seems to be a low-level conflict that hangs up the connection. I assume its either getty or USB driver(s). If I try to access the connection, say using A2V2 I get a device busy error. The USB adaptor from Keyspan has a green led that flashes when data is being transmitted. When getty is running via ttys it shows a solid green light, like its thinking, but it knows not what. Worst yet if I try shutting down or restarting the mini the machine will hang, obviously waiting for the USB port to finish up so it can get on with shutting down. The only way around all of this this is a hard rest, removal or commenting out the relevant line from /etc/ttys and another hard reset.

So close and yet so far....

I kept fooling around with options for ttys, wondering that was the cause, but to no luck. Being able to transfer disk images shows that the serial connection worked, so that isn't the issue. After some more futzing, I realized that if I couldn't get the setup exactly right, the next best thing would be to approximate it. That, I could do with GNU screen. screen is quite a handy swiss army knife type computer tool. At its simplest level it's a virtual desktop for the 'old-style' command line. screen however has all kind of features, including the ability to execute commands within a screen session, detach from a session leaving the executing command running and the ability to connect to a specified ttys device. Best of all everything screen does is in the standard vt100 terminal emulation mode by default.

To get everything going I startup Terminal on the mini and make sure the terminal windows is 80x24 (the screen resolution of the IIc). screen will adapt itself to this setting when launched. At the command line prompt the next set is to run screen on the serial connection:

$ screen /dev/tty.KeySerial1 1200

Then within screen its time to execute getty. The key combo in screen is Control-A and then Shift-: (colon again) and then to type is at the colon:

exec ::: /usr/libexec/getty std.1200

The three colons tell screen how to handle standard in, out and error, to connect the I/O of the serial device to the process, making screen a bridge between the running process, getty and Modem.MGR on the IIc. One can then login via the IIc and detach and close Terminal on the mini.

The Conclusion
Success, less windows on the mini, less clutter on the desktop and yet a handy terminal (and a retro stylish one at that) is up and running.

Two Loves

Now, I have to admit, running a virtual terminal program on the mini to get another terminal manager program to commutate to a third piece of terminal emulation software, just so the IIc can act as a 'dumb' terminal is a bit awkward. But hacking together a solution around a restrictive bug can lead one down a long and winding path. However, there is an advantage to this solution that I hadn't anticipated at the time, if I need to cut and paste something from the terminal to lookup, a URL posted on IRC or an error message from a process log, I can reattach to the screen process on the mini, cut and paste the info I need into Safari, and detach to keep the desktop a little less funky. Not to shabby, if you ask me.

In some areas, such as setting up a serial connection between a Mac or even a PC, and a Apple II, there is a lot of information and programs floating around on the 'net (I've adding links as needed within this post obviously). On the other hand, setting up a dumb terminal to a Mac, or dealing with conflicting ttys connections, there seems very little. Hopefully the information posted here will be a helpful in between for anyone else looking to attempt the same. And who knows, maybe someone out there has the information I'm missing to setup a cleaner, simpler connection. Or better yet I might end up at Apple, fixing the bug myself ;-)

Update: Well I knew a few people would be interested in this little project, but it seems I've started a little mini-fad. As a couple of comments below point out. Here are just a few of the more interesting followup posts:

Apple II Forever!

More Zoomshare Features Released....

| | | |

On the heels of Zoomshare Widgets comes picnik. picnik is a third-party website that provides online image editing and enhancement tools to the Zoomshare Photo Album. Think of it as a Photoshop-lite website. picnik's tools include everything from cropping and rotating images, to red eye removal, color adjustment and a slew of cool special effects. Zoomshare users simply click on the "Edit w/picnik" button for an album photo and then do the image editing right in their web browser, with no software to download.

What's really cool about both widgets and picnik is the ability to use more than one website or service without having to redo everything for each system. For example, you can have a Blogger account - where you share your thoughts with your friends, family and/or co-workers - and simply add a Flipbook widget from Zoomshare - where you keep all of your organized photos - to share those photos with the same audience. With picnik, you can now edit those same photos and dress them up before sharing.

In other words, you have something like this illustration, where you use the web service/toolset of your preference, but without the extra legwork of having to re-upload everything each time, since that's handled by us here at Zoomshare.

All of this represents some concrete examples of the current buzzword du jour, Web 2.0. In one of the many definitions of Web 2.0, the idea behind dynamic community websites is to facilitate collaboration and sharing between users. One could interpret that as meaning sharing between web services, since users, even the same user, has an account to more than one service. Thus, to help and keep a user(s) the service in question needs to facilitate sharing between services just as much as it needs to facilitate sharing between users.

The big question is how much (or for how long) will competing services facilitate sharing between services, keeping their various Application Programming Interfaces (APIs) open. Zoomshare wants you to post your Widgets anywhere, that's why we created the feature. But, Blogger is competition, after all Zoomshare has its own blogging tool too. MySpace, for example, won't allow you to post Zoomshare Widgets. Part is security, Javascript, which is the language our widget platform is built on, can introduce problems. But part of it is also business; MySpace wants advertising dollars for your eyeballs. So does Zoomshare and so do you, which is why each widget has a 'Powered By Zoomshare' badge on it. But we don't pay MySpace for advertising, so why should they allow our widgets, which can be seen as a form of advertising, on one level for our service, on another for your website?

Interesting, don't you think?

Technorati Profile

jun 06 07

| | | |

Hmm, no post in a while, I see. Must be all that wedding preparation that's going on. Hmm, nope, I know must be all those hours at work putting together cool things like this:

Yeah, that must be it! Read more about it at pdw @ zoomshare

Zoomshare Widgets

| | | |

Ok, time to write about something interesting, so here we go....

Today we here at Zoomshare released a new feature to our service called Widgets. As spooniep outlined in the forums Widgets allows Zoomshare users to embed multimedia and interactive features into their pages without extensive knowledge of web development languages such as Javascript. In this instance all of the developers here can apply their web development knowledge in a way that others can take advantage of, for just about any web page in their Zoomshare site. To that end some of the Widgets to be released in the coming months include adding a clock, poll or page counter to one's site.

Of course, these are nice features, but nothing revolutionary, people have been creating and adding page counters to their sites since the web began. The really cool feature of Widgets is the ability to share content across all websites, Zoomshare or not. In this sense, Zoomshare Widgets is a flexible tool for sharing along the lines of other Web Widgets such as Google's Desktop and Gadgets or MS Vista's Sidebar and Widgets. In fact, while it hasn't been a main goal of this release and thus is unsupported, our Zoomshare Widgets should be interchangeable with those widget platforms.

This is where most of my time in the last few months has gone into developing the basic framework and in creating the first widget that truly takes advantage of this new ability, Flipbook. With Flipbook a Zoomshare user can post any of their photo albums on any web page, Zoomshare or not, with the placement of a small snippet of code. In this way a Zoomshare user can share their photo album(s) in just about any web-based service they use, including social networks, blogs, wikis, forums and of course Zoomshare.

For example, I have a website dedicated to my upcoming wedding at http://wedding.weinstein.org. The site is hosted on Zoomshare and my fiancé and I can use the Zoomshare tools to create and manage the site's content, including photos. Until now anyone who wished to view the photos would have to visit a specific album, such as http://wedding.weinstein.org/ 6.shtml/Family to see any of the photos. Moreover, the viewing of individual images in an album is a bit tedious. Enter Widgets and Flipbook. With a little cut and paste of code provided to me from our new Widget tool I can share the Family album within this site, pdw @ zoomshare, in this specific blog entry and each image can be viewed without having to leave this blog entry.

Cool right?

Better yet, I can provide this code to family and friends, as shown below, and all they would need to do is cut and paste it into their own web page.

<!--zoomshare embed code begin-->

<script src="http://www.zoombricks.com/bricks/1.0/?url= http://www.zoombricks.com/bricks/1.0/album/album.xml&site= http%3A%2F%2Fwedding.weinstein.org/:album? album=Family&output=js"> </script>

<!--zoomshare embed code end-->

This being version 1.0 there are a few kinks to work out, but this simple example of sharing content across websites only scratches the surface (as I've alluded to in untested possibilities). So stay tuned, plenty of cool things to come from widgets!

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.


Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Movable Type Pro