This weekend I was trying to get an old CPM system running with via its 8" floppy disks. After troubleshooting it I found that the disk drive cabinet contained a Shugart SA801 Drive with a 230v 50/60 cycle Reaction Motor (capacitor start). I scoped out the index pulse to verify and it was running about 1.2x faster than it should (420 rpm versus the expected 360 rpm). Is there anything I can do to get this drive operational other than to sell it another who has a 230v/50 cycle environment. Thanks Robo

OR, . . . modify your disk controller to run at a differnt bit rate

Periodically, we get people in UK asking how to convert 60Hz Shugarts to 50Hz. Doesn't anybody see the simpler solution? Trade drives trade pulleys but is it really necessary to remachine the pulleys?

A clever trick if you can do it!. You can't get jeut any speed from such a motor. For a synchronous motor, IIRC the speed (in rpm) is (mains frequency * 60)/(number of pole pairs). I have no idea how many poles the normal motor is, but I doubt you'll be able to make one for the 'other frequenct' that uses the same pulleys. It is. The pulley is easy to remove and replace. IIRC the 50Hz conversion kit consisted of a larger pulley (so the surface speed of the pulley and thus the belt ended up the same) and a longer belt (to fit round the larger pulley). The spidle flywheel was unchanged. I thought the 800 and 801 were essentially the same drive anyway. The spindle motor should tbe the same in the 850 series (double sided) too. -tony

No, there isn't, but equally, you can't get just any speed you like. Given that there has to be an even number of poles, you are limited to motor speeds which are of the form 3000/n (n an integer) on 50Hz mains and 3600/n on 60Hz mains. This is for a synchronous motor -- an induction motor will run a little slower, there has to be some 'slip' between the rotating magnetic field in the stator and the mechanical rotation of the rotor to cause the necessary current to be induced in the latter. For example, a 4 pole synchronous motor (on 50Hz) will turn at 1500rpm, an 4 pole induction motor might turn at 1425 rpm or so. Of course. It's pretty obvious why when you think how these motors actually work. -tony

I just got off of the phone with Small Parts "AGAIN" and was informed that after messing around and dragging their feet for 6 months they finally decided to refund my money and were not going to be handling the items I ordered. You may not want to trust them with your money, I know that I can't... Chuck Guzis wrote:

Chuck Guzis wrote: I had seen Small Parts recommended on this list and had high hopes. I have now heard about every story in the book and from just about all levels so I now have my doubts about them. All of the suppliers I knew about are now history.

Hi In my earlier days, a friend had just the same problem. We took a file to the pully on motor shaft. We just turned it with the motor running. We did have to elongate the mounting holes on the frame. I suspect the the 50/60 cycle change had a different flywheel and pully or belt. Don't think of tape or something on the flywheel. The disk read is very sensitive to the slightest roughness on the surface of the flywheel. On old machines that I get, there is often tarnish and oxide on the flywheel. I usually clean and polish this before I expect the drive to work properly. The friend did use the SA800 for several years until he moved on to a PC. Dwight _________________________________________________________________ Get more done, have more fun, and stay more connected with Windows Mobile?. http://clk.atdmt.com/MRT/go/119642556/direct/01/

The change in voltage is presumanbly not a problem (in that a small autotransformer would solve that), the change in frequency is. Presumably you have 60Hz mains and the drive is set for 50Hz. There would seem to be 2 solutions : 1) Generate 50Hz mains somehow, You don't need much power, so a fairly small inverter circuit would do it. This is probabably the more complex solution, though 2) The motor says it'll run at 60Hz (and you've shown this). So a pulley (annd maybe a belt) change would get the speed down. Making a pulley is fairly easy o na lathe, perhaps you can find a local model engineer (the sort of guy who makes steam engines, etc, a 'Home Shop Machinist' is the same sort of thing in the States) who would do it in exchange for some similar favour. -tony

Hi Folks, It's been interesting taking out my old CP/M stuff and getting it operational again. My system uses an 8bit TTL Keytronics Capacitive Sense keyboard. It was operational for about an hour and then it quit. It turns out that the keyboard uses little sponge pads to hold the capacitive disks and they have biodegraded into dust. So I went looking for an old 8b TTL replacement keyboard. So far no luck. I also looked for a black box solution that would take an AT or PS/2 keyboard and convert it to a parallel port output. So far no luck. So let me turn to the experts and ask for advice and suggestions. Please advise Robo

Here is a PS2 to Serial Converter: http://www.electronickeyboards.com/keyboard-encoder.html I know you mentioned Parallel, but this may be a good starting point... Curt ROBO5.8 wrote:

Jos Dreesen / Marian wrote: They are <relatively> easily self manufactured. As long as you aren't picky about the keyboard "feel" any foam will do. I use a sharpened tube that fits into my IDC crimper along with a small piece of wood as a punch for the mylar and foam. I reuse the existing rigid plastic disks... the old foam and adhesive easily rubs off. It takes me about 1 minute per key. Bill

On Sat, Dec 6, 2008 at 6:30 AM, Ray Arachelian <ray at arachelian.com> wrote: I'm sure the foam response is different (different density if nothing else), but after reading your experiences, I'd be inclined to work with aluminum tape. It is literally a roll of aluminum foil, pre-glued, wax-paper-backed. I've used it quite successfully to make grounding strips on workbenches (just screw a wire to one end and run it to a ground bar via largish resistor). It's at least as thick as household aluminum foil, and the glue is quite tacky - more tacky than the glues I've seen on double-sided foam tape. Just a thought for another material that might be easier to work with than household foil, though what you used is arguably about the cheapest stuff you could find to do the job. If you've had any difficulties working with it, consider the aluminum tape. -ethan

Hi My guess is that you could use poly foam sheets to create the pads. Unlike the original foam, the poly would last a lifetime. Just a little time and some scissors. Dwight _________________________________________________________________ Suspicious message? There?s an alert for that. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2…

Here is another solution: http://www.swtpc.com/mholley/CT_1024/KBD5_Assembly.pdf Look at page 6 for the parts list, you could build your own PIO encoder board, you'll have to do some digging around for a 2376 keyboard encoder, but places like netcomponents.com and freetradezone.com are great sources for obsolete IC's Curt ROBO5.8 wrote:

On Thu, 4 Dec 2008, ROBO5.8 wrote: Jim Brain has a microcontroller setup for doing this. I use it to convert a PS/2 keyboard to parallel ASCII for my Vector Graphics machine. His microcontroller solution outputs both parallel and serial output simultaneously, so you can use either. Drop Jim an eMail. I can vouch that the thing works a charm. (In my case he just blew in the software into a ATMEGA8 and I built the circuit myself, with copious help from him and other friends). But he's an extremely skilled builder in his own right and would undoubtedly put it together for you at a very reasonable price. His eMail address is: j brain AT brain DOT com Replace AT and DOT as appropriate, and remove all spaces, including the one between j and brain. - JP

On 4 Dec 2008 at 14:14, Roy J. Tellason wrote: Why bother? AVRs and PICs are cheap and easy to work with (in particular, an AVR with SPI can be programmed with little more than a parallel port and a handful of resistors). Code for handling AT- style keyboards abounds. One DIP--that's all that it takes. I can see the motivation to do something "the vintage way", but even the 5170 uses a uC to interface to the keyboard. If you wanted to go "vintage', an 8048 or 8051-family uC would do the trick. Cheers, Chuck

Tony Duell wrote: It's weird, that... I suspect I could rustle up something 'traditional' around a Z80/6502, ROM, RAM and some decoding - but my brain just doesn't cope well with single-chip 'black boxes' such as PIC-based widgets. I really don't know why!

Chuck Guzis wrote: I wonder if it's a visualisation thing - when the components are separate I can more readily think of what's going on, as opposed to a single-chip solution. Still weird, though, I agree :-) I definitely miss assembly - I haven't done any in far too long; and you're right, it's a lot more satisfying than C. Not that I really mind C either, though - I'll either use that or Java over any other language... cheers Jules

On 7 Dec 2008 at 13:06, Alexandre Souza wrote: That's precisely what I call lame. An assembler with clumsy syntax that forces one to define constants as: .EQU Name = Value Terrible macro facilities. No strong typing or ways to form local variables. One can't even access the name of the label field in a macro invocation. I could compile a long list of deficiencies. There were far better assemblers in the 1960s, running on far more limited hardware. Perhaps the people who wrote the AVR assembler never had to code much in assembly. One might have argued in the beginning that these were only microcontrollers capable of running only a very small program, so what did it matter. But that's no longer true, which only demonstrates the limited vision of whoever wrote the development toolkit. I care less about an IDE than I do about the tools which comprise it. Give me an assembler which has at least the capabilities of, say, MASM 5.0 or S/360 assembler and I won't feel that I'm too limited by the tools. Of course, since AVR has an "official" assembler, improvments on the syntax and features are considered to be "nonstandard". So we code with a hood tied over our heads and curse the darkness. I know the standard answer--I've seen it on the AVR forums--use C. I think that's a cop-out. I can write C just fine, but I enjoy writing a well-crafted piece of assembly. Giving me a rusty screwdriver and a dull hatchet as a toolkit is shameful. Cheers, Chuck

Yes, you have. It is called ICD2. And of course, you can use a MCS-51 with external ROM/RAM. Why not? Sure you can. Have you searched for it? You cand do a In-Circuit-Debugger for less than $20 Sure.

I don't know PIC, but for the AVR equivalent the host requirements are an RS-232 port and the ability to run gdb. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

Can you program and debug either or both of these chips without propietary hardware or software. In other words, is documentation for the following availalbe (without signing an NDA, etc ) 1) How to send/receive words to the chip (what lines to wiggle and how, what voltages to apply, etc) 2) The binary instruction set 3) THe debugging commands/responses Could I, if I wanted, make the programmer and write the software from scratch? Hmmm.... That's not too useful if you don't have a single machine that supports USB... -tony

Yes. Everything avaiable.

Sigh. You'd think if they actually wanted to make the documentation _usable_, they'd make it plain text. Apparently glitz wins out over usability once again. Hm, I was recently looking for single-chip computers, and discarded the atmega stuff because the documentation digikey pointed me at didn't have an instruction-set section. (I ended up with Freescale's MC68HC908QY4.) Perhaps I should revisit them - do you happen to have a pointer to the instruction set documentation handy? (I perhaps could find it, eventually, but the Web searches that appear to be everybody else's - and in particular companies' - idea of easy-to-find information are difficult and unpleasant, not to mention often nonfunctional, for me. If you have it handy, that'd save me some grubbing around.) I assume they're more of those damned PDFs, meaning hours spent extracting the information from them into a form that's actually usable, but that's an overhead cost I'm willing to invest for a good microcontroller-style computer. (And more tree-killing, but that's going to be true no matter what form the doc takes.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Gordon JC Pearce MM3YEQ wrote: For sure - but 300MB seems excessive, even with a lot of diagrams. I suspect they employed someone who either didn't know about or didn't care about optimising file sizes. I don't care for PDF much, mainly because it gets so misused - but it is the only thing possible for jobs like this (unless people decide to use proprietary formats). It's just a shame that Adobe have bloated their reader out so much (but thankfully much smaller and faster free alternatives seem to exist for now) cheers Jules

Christian Corti wrote: Duh. My pre-coffee brain read '300 pages ' as '300MB' this morning - sorry :-)

Jules Richardson wrote: If it was plain text it probably *would* be about 300MB... Gordon

PDFs are _usable_ enough. Things change and progress. How would you include drawings on ASCII? Using ASCII ART?!?! Wake up, 2008 is now! :oD Heloo-ooow? :oD www.atmel.com - microcontrollers, atmel 8-bit risc, docs, http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf ?!? I just load it and read...What else is needed? :oO

On Tue, 9 Dec 2008, Alexandre Souza wrote: on material that is ALL text? source code? searching extracting not having to run multiple megabytes through a dial-up line to get a few pages of text print in a different font being able to make changes without needing special Adobe software

Which tools? The only open PDF reader I know of is ghostscript, and it doesn't do searching as far as I can tell. Which one am I missing? To integrate your hand-scribbled notes so they're there next time you look at it? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Dave McGuire wrote: Umm to remove the 'product is obsolete -- do not use in new designs' water mark.

or add them

Michael Lee wrote: To provide some "on topic-ness", since I've probably caused the thread to stray significantly. I can't help with old ASCII KBs, but I'm happy to modify existing code to offer an interface for NOS or new. With a 40 pin .6" spacing DIP and 1 external resistor, I should be able to provide 12x8 matrix scanning, ASCII output with strobe, IRQ for RESET/etc., and RS232 TTL level output of data. The solution should have enough pins left over to provide PS/2 KB input as well as RS232->ASCII conversion as well. A quick search does not bring up any NOS vintage KBs, though. Jim

On Dec 9, 2008, at 2:54 PM, Fred Cisin wrote: Gotcha...understood and agreed. I do wonder if that's really true. Yes, that is most infuriating. Some people should not be allowed to use computer technology. -Dave -- Dave McGuire Port Charlotte, FL

On 9 Dec 2008 at 11:01, Fred Cisin wrote: I'm somewhat in agreement with you here. To print 300-odd pages so that you can have the information at your fingertips (I work by having my documentation spread out on a table in front of me) is more than just slightly annoying. If the same documentation were at least converted to HTML online, I could browse to the pages that I needed, instead of downloading everything and printing it out. What's notable about the AVR documenation is that there's a table of contents of sorts, but no index. So one is reduced to leafing through the document until one finds what one needs. Ah, they don't write 'em like they used to. Cheers, Chuck

Doc Shipley wrote: But then the tools can be to blame, if they introduce a large amount of overhead into even the simplest files (akin to expecting MS Word to save good HTML, I suppose) That's where I dislike the ubiquitous use of PDF - in that for simple jobs, where you just need a few paragraphs of text and maybe an image or two, it seems to be quite a heavyweight format (ditto for the tools needed to display it). Unfortunately I don't think there's any real alternative, and possibly never has been (RTF, perhaps, but was that ever really an agreed standard?) cheers Jules

On 9 Dec 2008 at 14:30, Jim Brain wrote: If it's a document I constantly refer to, I prefer paper (with an index, if possible, not just a table of contents). My big gripe is with the oddball web search. Usually a PDF hit involves downloading the entire document. What slows me up is when I'm doing a search and I *think* that a Google search has hit paydirt, but I have to download the entire PDF and search it to see if it's what I'm looking for. (Don't even get me started on the inadquecy of Google's "View as HTML" feature!). Perhaps Google can spiff up its search so that it extracts just a few pages, converts them to HTML and points me there, like Google Books does. Maybe there's a search that already does and I'm just not aware of it. Cheers, Chuck

On 9 Dec 2008 at 17:09, Jim Brain wrote: Someday, I might be able to be that facile with my reading material. But I prefer to look down when I'm working on something in front of me, not up at a screen and grab my pencil and check things off or annotate them. You know, they call it a "desktop", but have you ever tried to put your lunch on the Windows variety, or use it as a support for a stapler? Damned things keep sliding off... Does anyone here stick their PDFs on an ebook reader to keep them handy? Cheers, Chuck

On 10 Dec 2008 at 9:31, Jules Richardson wrote: For the a few years, an outfit in the music biz has been attempting to sell an LCD sheet music display device to take the place of traiditional paper scores. It's quite expensive (about $1K the last time I checked) and hasn't yet addressed the questions of "What do I do when some idiot kicks my music stand over?" and "What do I do when the batteries fail in the middle of a performance?". Pencil and paper is still king for a lot of folks. Sketching out schematics or code is still easiest scribbled on paper for me. I know a number of music composers who wouldn't be caught dead using anything but manuscript paper and a pencil. Likewise, there's nothing quite like a printed databook. To those who suggest a service to print online PDFs, I'd also add that such services could also add an option to bind the result and print it on thinner stock than standard letter paper. Sounds like something the Rocky Ford Bill Gates might think up. (Is he still around?) Cheers, Chuck

I almost always carry a notebook. Not a notebook computer, but a good old book of paper. I find it more use than any electronic replacement Yep. As I've said many times before, I'll use a CAD system when it actually aids me in designing something (as opposed to hindering me, which most seem to). Until then, I'll use a 'Paper Aided Dasign' system, more commonly called a 'PAD' (of paper :-)). I design by sketching out scheamticvs and doing he calculations on a pocket calculator (and beofre anyone askes, I have scheamtics, machine language instruction set, and ROM listings for said calculator, OK :-)) Indeed... -tony

I find it completely impossible to design from a document on-screen. I can only work from the paper version. Of course paper has the advantage that I can read it anywhere, it never crashes, it never gives strange error messages, etc. And it withstands a hot soldering iron a lot better than any computer does :-) And I simply can't 'flip through' a pdf file (even on the fastest machines I've ever used) in the same way that I can flip through a book. I used to routinely flip through data books, etc and interesting devices would catch my eye. It's much more difficult doing that with pdf files. -tony

Um, if it's only six bits, it ain't ASCII; ASCII is a seven-bit code. (It may be a half-size subset of ASCII....) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

The two that immediately jump to mind are forth and lisp. BLS

A lot of the space is in the big libraries of stuff, especially for common lisp. XLISP is a good example of one that's more managable--and it's author is among us. There are also some really tiny schemes that can be used to bootstrap. I did think of ML, but decided against suggesting it because of the memory. Yeah, that does make stack operations slower. Years ago I started playing with a mental design for a language that was bootstrapped from a form of macros that directly specified machine code. The idea seemed like it was rich, but I never got far enough to see if that was a correct intuition. BLS

bfranchuk at jetnet.ab.ca wrote: Ben you have said these three things in this thread: (1) "Any good leads as am still looking for a small boot strapable langauge here." (2) "Tiny C will not work as my instruction set does NOT have register to register operations." (3) "I could do Forth but it would be slow as I have no auto-incriment registers and wound need to use memory variables." What is your goal? If you don't care to have any existing code base to draw upon, then you should be able to make up a language that *does* fit your weird-ass architecture, whatever it is. If you do hope to have some semi-standard HLL language so you can then run existing code, it sounds like you are off to a bad start if you can target neither a pared down C nor Forth. I don't see why the lack of register to register ops would prevent implementing a tiny C. There is nothing in the language that would demand it. Some of the Tiny-BASICs published in Dr. Dobbs early on were two level interpreters, kind of a specialized byte code. They would define some artificial machine code that was easy to implement on an 8b micro, and then wrote the Tiny BASIC in the artificial machine code. It made the interpreter slower, but it saved bytes and made it possible to move the tiny basic to another uP by rewriting just the artificial machine code interpreter. The Apple II ROMs had the SWEET-16 interpreter built in.

How about FORTRAN--say FORTRAN II or USA BASIC FORTRAN? Very small language; very few statement types and historically correct. Can be (and was) implemented on just about anything. You don't need registers, stacks or any of that fancy stuff. Seems that a dialect (LRLTRAN) was used to bootstrap operating systems at Lawrence Livermore back in the day. Some tiny BASICs also come to mind. Cheers, Chuck

On 11 Dec 2008 at 5:47, Cameron Kaiser wrote: Do you mean source code? It's not hard to write one otherwise. Manuals exist. Examples from the 60's must certainly exist. Note that we're not talking about F77 here, but rather a very limited dialect; something that could be run on a 360/20 or 1620. Consider the 4K FORTRAN for the PDP-8. Wasn't that cross-compiled on a PDP-6? Were there ever any tiny Algol-60 subsets marketed? Cheers, Chuck

Paul Koning wrote: We were taught Algol in 1st year Comp Sci, I quite liked it (except for the verbosity of "BEGIN"-"END") for it's regularity, but that may have something to do with it being the first structured language I experienced (various assemblers and BASICs prior). Waterloo version - I believe it was something near Algol 68, running in batch (cards) under MTS. PASCAL was used in 2nd year - seemed like a step backwards. (Anyone recall the MTS OS: Michigan Terminal System?)

Paul Koning wrote: I could be quite wrong about the "near 68". I just pulled out the textbook we used ("FANGET AN - an algolw primer"/1978), so the language was actually "AlgolW". It doesn't discuss the relationship to -60 or -68, so I don't know. I'm presuming the W is for Waterloo but I could be confusing that with WATFIV (Waterloo Fortran IV) that we also used, as well. It was all 30 years ago and I haven't used either Algol or Pascal since, but as I recall there was some limitation around Pascal that bugged me. (I tend to prefer curly-brace languages over BEGIN-END languages, but that's just another religious argument... )

I'll have to look through my collection of docs to see if I can find anything about the Algol compiler. Or perhaps this was a UBC addition that wasn't in the distribution? Yes. A friend attended UMich, and we used their machine for email. (Well, at that point it would have been one of their machines, as that was about when they started having two: UM and UB.) Helped him with a Pascal class once by taking my Osborne-1 down to use as a terminal. De

Brent> ...A few other people mentioned but no more about the origins of Brent> the language/effort. http://en.wikipedia.org/wiki/Algol_W says that it came from Niklaus Wirth (inventor of Pascal). That fits a vague memory -- it was a proposed successor to Algol-60 but wasn't adopted and Algol-68 was picked instead. This caused various big names of the time to go ballistic; I still remember getting scorched by Dijkstra when I mentioned Algol-68 to him (innocently; I didn't know any of the background at the time). It doesn't sound like Waterloo is the W in this case. paul

Paul Koning wrote: I do believe that having Edsger Dijkstra had gone ballistic on you probably gives you geek cred. 8-) Peace... Sridhar

I am sure I remeber a cut-down Algol 60 running under CP/M on the RML380Z computers we had at school (this would be about 25 years ago, in the UK). Alas I don't still have it, the RML:380-Z I bought second-hand didn't come with it. -tony

Having read his online trip reports and heard him lecture (sadly just the once) I think "being his student" and "being scorched" just go together somehow :-) Antonio

On Thu, 11 Dec 2008, bfranchuk at jetnet.ab.ca wrote: Don't count FORTH out. I've done a simple FORTH on PDP-8. My particular implemenation is extremely portable, being expressed in terms of a four-level fixed-depth math stack. This is not the math stack seen by FORTH, but is used to construct the FORTH stack; the basic idea behind the four-level stack is that it's used for working calculations much in the manner of an HP calculator. The FORTH system relies on a compiler crafted in C that builds the headers and compiles the simple stack machine assembly. Over the years, I've run the FORTH with 4-byte (VAX, i960), 2-byte (Z80), and 1-byte (PDP-8) cells, all with no changes to the basic FORTH code. Except for console terminal I/O and system startup, these systems have identical source even for those words normally done in assembly, because those are expressed in an assembly for the simple stack machine. On the PDP-8, the implementation is almost a bytecode. Each simple stack machine op compiles as a page-zero indirect jump through a word that holds a pointer to the implementing function. For the simple stack-machine assembly, the basic rules are that the math stack must be empty going into a branch or coming out of a label, allowing the compiler to track the stack depth. For the PDP-8, the compiler selects one of four functions to execute the primitive based upon the current depth of the math stack. Other implementations compile to assembly for the target processor, selecting the registers involved in each instruction based on the stack depth. On the PDP-8, the system requires approximately 3KW. Oddly enough, I've just been resurrecting it for a new project. This time, I have it compiling to a bytecode compiled with MACRO32 on an Alpha; the difficulty with direct compilation on the Alpha is that the MACRO32 compiler does not allow data and instructions to be mixed, which I circumvent by compiling to a bytecode. I had the following versions lying around: The new Alpha bytecode version requires 1765 32-bit words for the FORTH system compiled to bytecode and approximately 532 32-bit words for the bytecode interpreter, for a total of about 2297 words. I just got this version running today, so I know it works. The PDP-8 system, described above, requires 3262 words for the combination of FORTH code and primitive functions. This excludes space required for the math and return stacks; I place them at opposite ends of a chunk of memory growing towards each other. The Z80 version is implemented in a manner similar to the PDP-8 version, but subroutine calls require three bytes instead of the PDP-8's single 12-bit byte, so the code is a bit larger. It requires 4102 16-bit words. This version has also been run. I did, but did never debugged, a 68HC08 version. That one requires 2843 16-bit words for the combined system, but that does not include I/O because I never got far enough in that project to wind up with target hardware. The PowerPC version compiles the simple stack-machine primitives to PowerPC assembly. I don't think I ever ran that one, either. It requires 3973 32-bit words for the combined FORTH and primitives. The VAX version also compiles to assembly code instead of bytecode. I've run it both standalone on a MicroVAX 2000 and under my long-neglected port of CP/M to that platform. It requires 2347 32-bit bit words for the combined FORTH and primitives. I also have an ARM version that compiles to assembly code, but has never been executed; like the 68HC08 version, it has no I/O because I never got far enough to have a concrete target. That version requires about 2287 32-bit words for the combined FORTH and primitives. It is by no means a standard FORTH; it only has a couple of control structures, all numeric console I/O is done in hex, and it can't do inline string constants (i.e., no ." I have to declare a word containing the constant instead and then compile a reference to that word). Efficiency also was not a goal; the threaded code is position-independent, which makes NEXT larger (a design goal for the original i960 implementation was the ability to migrate the system from ROM to RAM so the EPROM it was booted from could be erased and re-programmed). The PDP-8 and Z-80 systems as a whole aren't position independent because the functions that implement the primitives aren't. It's small, primitive, and portable. I'll be using it to bring up some new hardware in the near future. -- roger ivie rivie at ridgenet.net

Dave Dunfield wrote: The architecture is like I said before a stretched PDP-8, with a 512 byte direct addressing range and more compleate set of alu operations. I am exploring the idea that 18 bits is still the best size word size for a small computer or digital controller. The extra opcode bit is used to support word & byte sized operands, compared to the that of a 8 bit micro. The two more address bits negate the loss of byte addressing and give a bit more room for a resident OS rather than swapping core in and out. Using CPLD's also gives me the feel that a 18 bit simple cpu like my design could have been developed as microchip computer similar to 6800 or 6502 chip set around the time the Z80 was developed. Using 48 rather 40 pins as packaging a 18 bit cpu with front panel support could have been developed. A) Cpu chip. B) Swr/data/address bus display support chips . C) data/byte swap buffer. Unlikely it will work , I have 9 bit bytes. I have hacked, Jones's PDP 8 assembler to cross assemble for me. Once I get the the single PCB board built later next year, then I will consider porting Micro-C. I plan to only have about 64Kb + bootstrap EEPROM, IDE interface and a two 6850 uarts along with a front panel. I am not sure yet if the IDE interface will be 16 or 9 bits wide yet.

Some further comments... Jim> Ben you have said these three things in this thread: Jim> (1) "Any good leads as am still looking for a small boot Jim> strapable langauge here." Jim> (2) "Tiny C will not work as my instruction set does NOT have Jim> register to register operations." Jim> (3) "I could do Forth but it would be slow as I have no Jim> auto-incriment registers and wound need to use memory Jim> variables." Jim> ...I don't see why the lack of register to register ops would Jim> prevent implementing a tiny C. There is nothing in the language Jim> that would demand it. Agreed. Consider that C was first implemented on a machine that doesn't have such ops. And for that matter, doesn't have auto increment ops either. Similarly, you don't need stack ops to have a stack; C compilers exist for plenty of machines like that. (The 360 comes to mind -- gcc handles that. And I know there was a C compiler for the CDC 6000 series, though it appears to have been lost.) In any case, I second the suggestion of Forth. Forth was originally designed as a real time control system language; it's both fast and small. The limited instruction set Ben mentioned will make some difference but I doubt it's large, especially since memory is pretty fast compared to the CPU of low end machines. I've done some large scale worth with FIG Forth; a full port of that to a PDP-11 which (if memory serves) took 8 kbytes. That was usermode code, so no drivers (but instead OS interfaces, which is probably not all that different). Another place where Forth has been used: several popular workstations use it for their bootloaders. Sun does (or did) and I think Apple does too. At least I once got an "ok" prompt when I powered up a very confused Power Mac... and it answered like Forth interactive mode. Porting Forth is very easy because most of a Forth implementation (FIG Forth is a good example) is in Forth; only 10% or so is assembler for the target machine and these are low level primitives that are easy to design and code. That leaves some drivers, which you can code in Forth, and if the hardware is at all close to industry standards (like a UART probably will be) you can just use a stock driver and drop it in. paul

On Dec 11, 2008, at 10:42 AM, Paul Koning wrote: This is correct...it's called Open Firmware, and it has been the ROM-based boot facility (and some other neat stuff) in all SPARC- based Sun systems from the SPARCstation-1 on up to the current hardware, all Apple PCI-based PPC systems, and many IBM POWER-based (RS/6000) systems. Sun calls it OpenBoot. The OLPC XO-1 laptop (based on an AMD x86 implementation) also has Open Firmware, and probably other machines as well. Open Firmware is an IEEE standard (1275) and can be implemented on just about anything. It is well documented, portable, well behaved, and used to great success. In the face of these facts, one wonders why things like EFI are brought into existence. What seems to surprise most people is that this makes Forth one of the most widely-deployed languages in modern computing. I recently had a conversation with an otherwise extremely clueful guy who even has a background in embedded systems, who thought Forth was completely dead. He was shocked to learn that the Mac he was typing on had a Forth implementation in flash. As you observed, it is indeed Forth. It's an extremely powerful and well-thought-out system that allows expansion cards to contain machine-independent code ("FCode", Forth bytecode) in ROM or flash that implements initialization and diagnostic routines, bootstrap code, and OS-accessible/-usable device drivers. If you've ever noticed the flash chip on Sbus cards...that's what's in there. Some PCI cards have it as well; the world would be a much happier place if all of them did. So, one other implication here is that any old SPARCstation sitting in a closet makes a great Forth hack machine. -Dave -- Dave McGuire Port Charlotte, FL

bfranchuk at jetnet.ab.ca wrote: You could run a Brainfuck interpreter from ROM in a few hundred bytes :-)

Tony Duell wrote: PDF is a well-documented standard, with many different open-source readers. There's nothing to stop you porting one to the Perq. In terms of the time and effort it would take to do so, I'd say you'd be better off picking up a PC capable of running some sort of PDF viewer on modernish hardware. Gordon

Unrealistic? Tony's lived that way for...I don't know, but at least as long as I've been on the list. Take off your "it has to work for all environments, or at least my environment" blinkers for a minute. Your stance is at least as unrealistic for Tony's environment as his is for yours. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Well, it probably is commercially, but it's not for a hobbyist. I don't _need_ the latest machines, I can do all I need with my classics. And those I understand. Agreed, I think we have misundertood each other, and actually I agree with much of what you say. Commercially, there must be trade-offs. I guess everything is ultimately goverend by money (I wish it wasn't, but that's the way it is), and thus you have to weigh up the cost of buying the right tool, the cost of supporting it and the cost of learnign to use it against the cost of making it from sceatch (and the materials needed to do that if it's a hardware rather htan software device), the cost of supporting that, and so on. I totally agree with you. Of course things are different when we're talking about a hobby (and to be honset, for most people on this list, classic computers are a hobby). You do things them because you enjoy them, not because it makes financial sense. It doesn't amke financial sense to spend several months writing the repair manual and then restoring a desktop calcaultor when you canbuy a much more powerful pocket calculator for less than the repair parts for the old machine cost. But none-the-less I did just that a couple of years ago, and I enjoyed every minute of it. It's a hobby, so why not :-) Similarly, if somebody wants to write an OS for the PDP11 as a hobby (given there are already quite a few OSes for that machine, at least one of which would probably be suitable), then I see no reason why they shouldn't. No, I don't, after you clarified your position. -tony

Now that this topic has strayed far from TTL keyboards, and into either PRO or ANTI PDF formats, can we at least change the subject line? Please? Drifting off subject does tend to be endemic here, please, do change the subject line once it has nothing to do with the conversation. <rant> It's perfectly fine to discuss it as it does relate to our hobby, and yes, it's over 10 years old ( http://en.wikipedia.org/wiki/PDF ) IMHO, I think PDF is wonderful. It does a far better job than HTML at rendering documents. No, I'm not proposing the replacement of HTML on websites with PDFs. It can be better than PostScript in terms of the compression and can be searchabe. For example, you can guarantee that the font you want your document to be displayed in doesn't have to exist on the viewer's machine or printer. Unlike PS, it can have a table of contents and bookmarks. For our hobby, you can use it to scan in large paper documents, and OCR them, but display the images instead of the unreliable OCR'ed text, and use the OCR to allow the end user to search. PDF's were designed to be portable, that's what the "P" stands for. It's an open standard. If you don't like viewer from Adobe because it is bloatware, (and I don't) there are alternatives. There are also plenty of tools with which to create PDF's, including imagemagick which is useful if you've scanned in an old 500 page document. Yes, it can be much more expensive than HTML, 50M PDFs are quite common, but it does offer a lot of advantages over plain text and over HTML. But to save a document as HTML means to have it saved as multiple files, which would include style sheets, images, and other stuff. Plain text may be considered a standard, but whose? EBCDIC or ASCII? ASCII or PETSCII? or ATASCII? CR? CRLF? LF? 7-bit or 8-bit? If it's 8-bit whose encoding? How do you italicize, underline or bold with plain text? (Yes, I know, if you're printing, you can send back spaces and stamp over the same character multiple times to do underline or bold, or accents, but what about on a CRT?) That said, I do think that plain text is wonderful, except as mentioned, there's really no such thing as true plain text. RTF? Meh, some of us are allergic due to it being a blood-relation to that monstrosity from Redmond that claims to be a program that supposedly processes words. Good luck trying to edit RTF with something like vi - far worse than HTML. Yes, PDFs can be evil, you can prevent the end user from modifying, copying, or printing the document. Yes, while working at a hedge fund many years ago, I saw that someone had written a DRM plug in for Acrobat (and Acrobat only at that) that locked down documents for viewing only by specific machines. Yes, I think HTML is wonderful too. I dislike the syntax, and I don't agree that XML and its derivates are really human readable - they can be, but a lot of the time they aren't, and there are a lot of problems with HTML - namely that CSS and HTML have completely different syntaxes so if you wish to edit web pages, you have to learn a ton of stuff, and it can be painful, but at least I can almost always use vi to edit HTML. So as with everything, there is a right tool for the job. If you feel RTF or HTML or plain text (whatever that means) is the right tool for the job, use that. Tools aren't bad or good or evil, they're just tools. Blaming the tools is silly. Nobody is forcing anyone to use a hammer with to nail a screw, especially when screwdrivers exist. </rant>

der Mouse wrote: That's because ghostscript is based on a long-obsolete version of the standard, as far as I can see That's fine, if you want to stick with bloated plain-text documents and live without usable searching, indexes, annotations and bookmarking. Please stop railing against the rest of us, who have moved onto better things. Gordon

bfranchuk at jetnet.ab.ca wrote: No, plain-text files, with .doc as the extension, because then Firefox cranks OpenOffice into life, which then complains that it's not a *real* .doc file and would I please be more careful in future? Gordon

der Mouse wrote: .txt doesn't hold diagrams. Obviously, both formats are useful. Since space is cheap, I always store my scans in three formats: - Compressed TIFF - PDF - .txt That way the original TIFFs can be re-processed in a decade with better tools, the PDF is available to distribute and has full text search + diagrams, and the OCR'd .txt is available for those who are just looking for the text data. That's the final solution, and anyone arguing for a single format for scans of datasheets (or any documentation!) is missing the point, all parties included. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

Good point; thanks for catching that - I suspect I've seen too many concordance-style indices and too few of the other sort. But even a good index can be done perfectly well in plain text; the only part that's at all difficult is what to use as the pointer to the referenced text, and that (a) is an issue only if the text is not broken into numbered pages and (b) is not hard to solve even if the text is not paginated (it could use line numbers, section numbers, even search patterns, etc). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

It is a variant of the <a href= tag To another page it would be <a href="pagename.htm">, for a position in that page it would be <a href="pagename.htm#position">, where 'position' is a tag in that page <a name="position">. Mike ----- Original Message ----- From: "Fred Cisin" <cisin at xenosoft.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Wednesday, December 24, 2008 7:52 AM Subject: [personal] Re: PDF datasheets (was Re: Sources for 8b TTL keyboards(Keytronics)) >> >> of pointers is valuable.) >> > A good professional indexer works with synonyms and subject, not just >> > keywords. A keyword only index is basically a concordance. > > On Tue, 23 Dec 2008, der Mouse wrote: >> Good point; thanks for catching that - I suspect I've seen too many >> concordance-style indices and too few of the other sort. But even a >> good index can be done perfectly well in plain text; the only part >> that's at all difficult is what to use as the pointer to the referenced >> text, and that (a) is an issue only if the text is not broken into >> numbered pages and (b) is not hard to solve even if the text is not >> paginated (it could use line numbers, section numbers, even search >> patterns, etc). > > > > -- > Grumpy Ol' Fred cisin at xenosoft.com > > >

On Wed, Dec 24, 2008 at 2:00 PM, Tom Peters <tpeters at mixcom.com> wrote: That form certainly only works within the same document (I've used it plenty), but I'm surprised to hear the suggestion that it might not be standard. I've been using it since 1995 and Netscape 0.8. I check my web pages against modernish standards with the W3C checker and I get no complaints about it. -ethan

It's been working fine for me - I just see it as being a short jump and as sort of a "local variable" assumed to be within the same file, just as a URL without domain is assumed to be a file on the same server. I guess that I'd better start studying the standards to make sure that what I do is kosher.

On Wed, 24 Dec 2008, bfranchuk at jetnet.ab.ca wrote: Thanks. I do often forget to change the subject line. -- Grumpy Ol' Fred cisin at xenosoft.com

At 01:04 PM 12/24/2008 -0800, you wrote: HTML can be rendered so radically different on various platforms. What would the offset measure? Bytes? Characters? (those two would be very different) Lines? How could you possibly compute that? Would a byte offset be meaningful? A byte offset that lands you in the middle of a script or code of some other type would be the same screen position as a byte offset that's hundreds of bytes (or thousands) different; how would that be useful? Ever see a web page rendered in Lynx? It's just text and nothing more. The whole point of a web browser is that the content is rendering engine independent. I think that some sort of offset is a step backwards and is unlikely to be implemented. Just my $0.02 ----- 311. [Philosophy] No, I don't think smoking should be illegal. Smokers are already getting the death penalty! --from Stev0's "rant of the week" on smoking --... ...-- -.. . -. ----. --.- --.- -... tpeters at nospam.mixcom.com (remove "nospam") N9QQB (amateur radio) "HEY YOU" (loud shouting) WEB: http://www.mixweb.com/tpeters 43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square EN53wc WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531

I need to apologize to Tom Peters. The world moves on and I can't always keep up. He pointed that out, but he doesn't deserve to be a target of my frustration. -- Grumpy Ol' Fred cisin at xenosoft.com

On Thu, 25 Dec 2008, der Mouse wrote: [. . . lots of content more articulate than mine deleted . . . ] and being able to identify the location of an item within and FOR content analysis software, particularly indexing. It is refreshing (and a mjor uplift on XMAS) to see that some people understand that there is valid need for pointers at levels below file, and even below that of markers provided by the author. -- Grumpy Ol' Fred cisin at xenosoft.com

On Dec 24, 2008, at 2:52 AM, Fred Cisin wrote: Does the '#' construct not do what you want? -Dave -- Dave McGuire Port Charlotte, FL

On Wed, 2008-12-24 at 13:12 -0800, Fred Cisin wrote: This is what XPath is designed to do. It's a query language which works within XML documents (so XHTML, not sure how well it would go on HTML). This allows you to point to (say) the 5th <p>...</p> block following the 8th <h2>..</h2> heading. I think this is: /body/descendant::h2[8]/following::p[5] They probably exist, but I can't find a site that lets you enter a URL and an XPath query and gives you the result, but there are (e.g.) Firefox addons to do this, and a few sites that let you enter some XML text and then try the XPath query, such as: http://www.bit-101.com/xpath/ -- Lawrence Wilkinson lawrence at ljw.me.uk The IBM 360/30 page http://www.ljw.me.uk/ibm360

Fred Cisin wrote: Are you asking how to get < and > rendered as displayed text? Try: ...the &lt;BOLD&gt; tag will... (I'm not sure how I know this, I can't find it in the html reference I use; which begs the question of whether it's actually part of the standard.)

On Wed, 24 Dec 2008, Brent Hilpert wrote: &lt; is the "less than" character &gt; is the "greater than" character how would you get HTML to display: "&lt; is the "less than" character" would I have to "escape" the ampersands? &amp;lt; <pre> , </pre> are fun. Is there an inconsistency with whether a browser will display special chatacters within a <pre> block? Do some browsers display them literally, while others apply the <pre> ONLY to whitespace and line breaks? I have seen at least one browser where I could get away with: <pre> x = &lt; if (x < y) . . . </pre> I guess that "modern" HTML has evolved to the point where one MUST use an HTML generating program, and no more tampering with the raw HTML; just as "nobody" writes Postscript. -- Grumpy Ol' Fred cisin at xenosoft.com

SORRY FORGET ALL OF THAT. It appears that modern/current (less than 15 years old?) browsers do NOT permit '<', '>', or even "&lt;" within <pre> blocks, and require "escape"ing certain characters and phrases. You can NOT simply slap tags around a chunk of text to quote it. I don't remember which browser I had encountered that in, but it's not around any more, and not compliant with current specs.

I use a very modern HTML editor. It is called vi. Merry Christmas, -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Perl scripting: the ultimate open source software. -------------------------

Yup, I'm pretty sure I have some dating back nearly that far. Hand-coding isn't just a good idea for learning HTML, it really causes people to make leaner documents. People forget that HTML is, as its acronym implies, a markup language. When people use a page designer, they tend to forget that. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Glory is fleeting, but obscurity is forever. -- Napoleon Bonaparte ---------

In article <f4eb766f0812242215gddae341re6920fb1fe5d85d3 at mail.gmail.com>, "Ethan Dicks" <ethan.dicks at gmail.com> writes: LOL. Maybe about 10 years ago it was that way. There's this little thing called ASP/ASP.NET... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

On Thursday 25 December 2008, Richard wrote: I'm pretty sure that Ethan was referring to HTML that he has written. It would seriously surprise me if Ethan has ever used that. In fact, I'm willing to bet that PHP is more popular than ASP. In any case, what sane person runs Windows on a web server, who has a choice? *sigh* I've used ASP. I really hate VBscript. I'd rather write CGI programs in C (which I've done before), which alone isn't much fun. Pat -- Purdue University Research Computing --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

On Dec 26, 2008, at 2:41 PM, Jules Richardson <jules.richardson99 at gmail.com Or (and I realize this is -complete- insanity...) -- it's possible that Windows and IIS do what they need? Gasp! Josh

On Friday 26 December 2008, Jules Richardson wrote: That's why I said "who has a choice." The reasons you mentioned eliminate the posibilty of choice. Pat -- Purdue University Research Computing --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

On Fri, Dec 26, 2008 at 3:18 PM, Patrick Finnegan <pat at computer-refuge.org> wrote: You are both correct... I started writing HTML in 1995 this way and still do it that way mostly. To be fair, I'm not in the business of writing it (I do it for fun), so commercial feasibility is not part of the equation. Quite so. Perhaps, but I've had my brushes with PHP and have some issues with certain aspects of it. *ding*! When I was working at CompuServe (after they were bought by AOL), we had a directive come down the pipe for all parties running Microsoft web servers to provide the date they'd be shut down. There was no room for debate - you had to pick one of like *four* acceptable web platforms (including Apache), but MS was not allowed, period. I've done CGI in C. It wasn't so bad, but I do recall that debugging wasn't as easy as the Perl CGI scripts I've done. -ethan

On Thu, 25 Dec 2008, Ethan Dicks wrote: I may be misguided, or simply WRONG, but I was not deliberately trolling. My remark about evolution of HTML and "nobody" [notice that I put it in quotes!] was a rant and sarcastic comment about modern attitudes (and how I don't fit). We have a higher percentage of RAW coders here than the general population of "professionals". -- Grumpy Ol' Fred cisin at xenosoft.com

Fred Cisin wrote: Just to clarify, I presume everybody dealing with html knows about "&blah;" for special characters; what I don't see in the ref I have is the 'lt' and 'gt' in the list of special characters. I either saw them in an example somewhere or guessed at them. Well, I guessed at that one too (presaging the question), and it works. If you're complaint is that html is poorly defined in the detail, or difficult to find a good concise reference for the details, I'm right there with you. All the books I use to run across about html in the 90's were voluminous hold-you-by-hand and walk-you-down-the-garden-path blatherings that took ten pages to tell the simplest thing and still couldn't manage to be comprehensive. I eventually found one that was 90% fluff (not an exaggeration) but the remaining 10% (the appendix) presented a reasonable reference. I still do hand-coded html for web pages, probably considered ugly by current expectations, but at least makes for fast and consistent loading and rendering.

Jochen Kunz wrote: I tried that. Down that path madness lies. It's far better to just store the text in a database, possibly marked up in one of the "simple" markup languages like markdown, and serve it up as required. Computers are good at stuff like that. Humans aren't. Gordon

Cameron Kaiser wrote: Any sane distro will either have a database installed or one easily installable. It's not hard. If you use a framework that uses the active record pattern (like, maybe Django) then you never even see the database. Objects just appear when you ask for them, and you call save() on them when you're done. Some people just seem to like doing things the hard way. Gordon

On Wed, Dec 24, 2008 at 06:35:24PM -0800, Fred Cisin wrote: Now that's nonsense. There are plenty of people for whom "HTML editor" translates to vim, emacs or another TEXT_EDITOR_OF_CHOICE. Writing HTML markup by hand is very easy and usually results in more readable (and less crap-littered) markup as well. In that case, there are also quite a few nobodies around ... Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison

Alexander Schreiber wrote: Indeed. Actually, I usually 'first pass' code generation by simply doing "cat need to make changes*. But then I detest both complex HTML and complex website interfaces; I believe in HTML being used to add a little structure so as to better convey the information within - it's not the ideal mechanism for "busy" graphics-laden interactive interfaces (that it's the only mechanism we have these days is beside the point :-) * In my day it was uphill both ways etc. etc. Heh, yeah. It's been a long time since I've hacked postscript by hand, but I have done it before. cheers Jules

My rule of thumb: if the site isn't sane in Lynx, I redesign it. It may not be perfect, but it should be navigable. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- It's not Camelot, but it's not Cleveland either. -- Boston mayor Kevin White

In article <4952EA33.22FE312F at cs.ubc.ca>, Brent Hilpert <hilpert at cs.ubc.ca> writes: Yes, its part of the standard. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

On Thu, 25 Dec 2008, Chuck Guzis wrote: During the process of implementing a pointer structure for use with STATIC pages, it would be wise to also contemplate how to extend it to volatile pages, but NOT to forego implementation based on the possibility of difficulties in future expansion.

On 27 Dec 2008 at 22:42, Gordon JC Pearce MM3YEQ wrote: Going further OT, I wonder what Google will do with a dynamic page that changes content drastically every time it's visited.... Cheers, Chuck

On Wed, 24 Dec 2008, Sean Conner wrote: Yes. One particular project was to create an add-on index to an existing CDROM of literature. -- Grumpy Ol' Fred cisin at xenosoft.com

Jules Richardson wrote: Doesn't that describe Mac OS X Aqua? Peace... Sridhar

Jim Brain wrote: Agreed.^M However, my objection to the "TXT FOREVAR" idea goes past that.^M Even straight ASCII text isn't bulletproof or all that standard.^M Doc^M

Jim Brain wrote: I wonder if it's just suffered the same way HTML has - perhaps back in the day it was a good format for quickly laying out simple text, but then over the year has been completely wrecked by "let's just add this feature" syndrome?

PS isn't supposed to be machine dependent either. In fact it rather goes out of its way to make it difficult to be machine dependent, unless you just punt and use nonstandard words defined idiosyncratically by the PS engine you're using. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B