Since when does being interested in vintage Macs require a degree in computer programming? I'm not frightened, just have no interest in it. There are many folks on these forums who maintain their vintage equipment, but have no interest in learning to program for them, but rather using them. To that end, I can take apart and re-assemble and maintain the hard ware with the best of them. We all have our strengths and that's where the beauty of a community comes together. Also, I'm not demanding anyone write a program for me. I'm looking for solutions.

Click to expand...

All I'm saying is when someone suggests a solution you tend to go straight to shooting it straight down with the objection that it's "too hard", which sort of turns anyone who *could* give you step-by-step instructions off from doing so. If you'd like to pay someone $100 an hour in consulting fees I'm sure you'll find plenty of people happy to craft a custom solution, install it, and provide custom documentation and training for you. Short of that, well... I guess it just it seems to me that if you want to participate in a "DIY" hobby it behooves you to take on some of the responsibility for tackling the "Doing" parts.

(I'm sorry if that sounds condescending. If your skill set doesn't include "programming" or "UNIX" that's fine, be the idea man, but I guess the thing that bugs me that when you're discussing things in those categories all you can say is either how little interest you have in them or how much you hate them. Why should someone *with* UNIX skills help you when all you have is contempt for what they do?)

But you keep saying I have to learn to use terminal-window programs ... why? I already told you I use MacTerminal. It is 100% a Mac GUI program. While it is essentially an interface like OS X Terminal, the two could not be more different to use.

Click to expand...

Uhm, what do you use it *for*? At its heart, all a "Terminal" does (file transfer and other secondary functions aside) is display characters from "a program" and feed keyboard input back to "a program". What's important is what you *run* using a terminal. MacTerminal and OS X's Terminal are similar to the extent that both supply an interface for running text-based software. MacTerminal is for running that software on a remote computer while OS X's terminal is for running programs on the local machine, but in either instance what's important is *what you're running*. A text-mode program can be a friendly menu-operated fullscreen application or a horribly obscure and unfriendly command-line utility. It seems to me like you lump *all* text-mode software into the same "unusable" bucket.

Of course, just for fun, look at MacTerminal side-by-side with a terminal emulator on a PC from the original 1984 Macintosh Newsweek spread. Oh, wow, the Mac *totally* looks more user-friendly. Not.

If you're going for "what I can do with existing software that runs on a 128k Macintosh", there it is. If you had a Mac in 1984 and wanted to send an email you'd log into Compuserve with MacTerminal and use the same text-based interface as anyone else. By installing a few programs on an OS X box and setting up your Mac as a serial terminal you'd basically replicate that experience.

Of course, again, it seems like you've preemptively said you hate running text-based software, period, so clearly any "MacTerminal" based solution is going to be completely unacceptable. Thus it's certainly not worth the effort spelling out how to do it.

Also, there were plenty of e-mail-type programs written for the 128/512K which mask the terminal interface for the user. All the user did was start the program, type the message and it got sent through the BBS system and likewise received relies.

Click to expand...

Do you have an example of such a program? Presumably they worked with some specific BBS backend. You could always write a UNIX program which replicates the same menuing system for various functions and could drive one of those programs. But, wait, that's programming again.

To do any expanding of the funcationalilty of the 128k like you describe you are going to have to do real programming ( Pascal, C or assembler ).

Click to expand...

You couldn't be more wrong. I've done plenty with the 128K and modern computers using only what was written for it and finding clever ways to interact with OS X. I have absolutely no interest in programming for the 128K. Also, as Gorgonops deduced this is a OS X-side Unix solution not a 128K-side machine language, though it every well could be done that way ... why?

Click to expand...

Here's where you're sounding schizophrenic. Do you want someone to tell you how to put existing tinkertoys together into a text-mode way of accessing the internet (and thus putting up with the limitations inherent in such an approach), or do you want someone to bake a special "Mac-y" way of emailing from your old doorstop? Anything from the second category means some programming gets done *somewhere*, whether it's bending the UNIX machine to the will of some existing antique GUI BBS software or writing a Mac-side GUI presentation layer for existing UNIX text-mode software. There's no avoiding it.

(Although I guess I'll allow for the vanishingly slight possibility that some BBS software which was both compatible with some existing "GUI-BBS" client for 128k Macs and included internet gateway capability is still available and will still compile on something approaching a modern platform.)

Or do you want a genuine TCP/IP stack for a 128k Mac? (It's so difficult to tell what it is you're actually asking for.) If it's TCP/IP it's probably doable in some limited way, despite your flat statement to the contrary. Here's a micro-sized TCP-IP stack that can work in a few K on an 8 bit microcontroller and supports SLIP. It would probably be possible to incorporate it into a *really limited* Net-Tamer-ish network client that could fit, just barely, in 128k. But, again, someone would have to program it.