> Nowadays, of course, it's difficult to
> get many of the books or raw materials we used back in the Sixties.
Actually, I have a small packet on how to build a 'sugar rocket', which I
ordered for something like $20 a few years ago. I never built anything, but
sometime, I ought to try. The same company also has a full-blown book on
making rocket engines.
At 08:03 PM 1/15/99 +1, you wrote:
> ...
>> The first hard disk was made by IBM around 1956, and I assume it didn't
>> take them much longer to write a DOS for it, but I don't know when they
>> did or what it was called.
>
>Didn't they already use the term DOS ?
The first commercially available IBM disk system was the IBM 305 RAMAC, but
I believe the disk was just a peripheral device like a tape drive, not a
system disk like we view it today. There certainly was no operating system
stored on the disk and I doubt they even stored a program on the disk. It
was pretty small electronically although it was physically huge, and
incredibly slow because it only had one read/write head that had to be moved
>from disk platter to disk platter.
Since all IBM computers of the era, the 700's and 7000's were punch card fed
machines, the programs were stored on punched cards and loaded each time
they were to be run. Tape drives held intermediate results and input and
output data, but not programs. At some point the the 7000 series life I
believe there was a primitive "Tape Operating System", or TOS, developed so
that once a program was debugged, the compiled binary version could be
stored on tape, and a punch card "IPL" program could read that tape, load
the program and then the machine would continue on just as if it had read
the program from punched cards.
After the 305 RAMAC was designed, a disk drive that I believe was called the
2305 was developed and it was hooked to the 7000 series machines. At some
time around 1964 IBM coupled a 2305 to a 7044 which had a Direct Couple
interface to a 7094 and used the 7044 to stage and control program loading
on the 7094. A primitive "DOS" was developed called IBSYS, but all it did
was que programs and data on the disk to be run on the 7094, one program at
a time. This greatly minimized operator setup time and kept the very
expensive 7094 humming. I don't think it was until the delivery of the
S/360, in the 1968 time frame, that IBM had an operating system that they
called DOS, but maybe there is an IBM expert in the group that could comment.
-- db
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dean Billing Phone: 530-752-5956
UC Davis FAX: 530-752-6363
IT-CR EMAIL: drbilling(a)ucdavis.edu
One Shields Way
Davis, CA 95616
At 01:49 AM 12/30/98 -0600, you wrote:
> 1) do a color scan to grab images
> 2) clean up images
> 3) resize based on guess at a good size and res for web pages
Don't think you can do much about these steps. I usually shoot for 320x240
pixels for web images -- on most monitors that's about 4" by 3" or so. It
used to be (not sure if this is still true) that the default width for
netscape on the mac gave you 400 pixels across; I believe on the PC it was
480? (I'll have to dig up that article again.) Also, that's a manageable
size for downloads.
Anyway, on a 640x480 screen, you lose some width for scroll bars and all;
plus you need a border/margin... Sure, you can design your web pages for
800x600, if you don't care that most people won't be able to see it all at
once.
> 4) scan again as B/W line art
> 5) OCR
> 6) clean up OCR
> 7) create HTML combining OCR'd text and images
>
>I don't much like PDF for web docs, so an HTML solution would be best. It
>looks like the "pro" version of Xerox's OCR software might automate the
>task somewhat. Any recommendations?
Well, your main issue is getting the text into machine-readable format. My
current belief is the best way (especially for lower quality originals) is
to read them into a word processor using dragon dictate or similar. Once
you've got a text file, there are several options to get them HTML'ized,
including things like MS Word, and HTML editors. (I prefer doing it
manually.) Depending on what you're doing, a CGI program that
reads/formats text files, inserting images as necessary, might be the way
to go. (See http://www.sinasohn.com/clascomp/index2.htm) for an example.)
--------------------------------------------------------------------- O-
Uncle Roger "There is pleasure pure in being mad
roger(a)sinasohn.com that none but madmen know."
Roger Louis Sinasohn & Associates
San Francisco, California http://www.sinasohn.com/
<While I realize that it would not have been possible to make
<their graphics part of the standard OS for a PDP-11, I
<was led to believe that the PR0 350/380 had access to
<their bit mapped screen displays. While doing such
<manipulations was likely discouraged, is that a true
POS did have a color and somewhat graphical display (menus on color
screen) that was far from being graphics like most describe. Also the
Graphical part was really not inherent to the basic OS, IE: no mouse or
other object linking or support.
The PRO350 also was contemporary to the PC XT making it a mid life PDP-11
based system. While -11s were used for graphics most of the serious work
really required specialized hardware and programming support not generally
available at the time.
<Also, I understand that the first RT-11 was released about
<1973.
>When was the first CP/M released?
1974 (late) and was based loosely on Tops10, RT-11 and OS/8 (DEC Command
line styles).
> And the first DOS?
Before 1970! Dos for PC was 1981ish. TRSdos was '78ish, NS* dos was late
'76.
DOS used to be a generic as well for "disk operating system".
Allison
<As I recall, some of original Star War's movie graphics were done on a
<PDP11.
I don't think so. They used masks and other film tricks. someone else can
comment.
Though the -11 had graphics. It was more that any graphics were not
supported by the OS and the hardware to do that was likely as big as the
machine itself and not anywhere near real time. Graphics need lots of
ram and lots of disk neither of which where common then nor cheap.
Allison
For my very first eBay auction, I managed to sell a single blank floppy disk
for $22.00:
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=51510929
Of course, it wasn't your average, run-of-the-mill diskette; it was
a classic, or I wouldn't be talking about it here. :-)
Happy New Year!
Eric
[If I hear one more person joking about partying tonight like it's 1999,
I think I may go postal.]
<I was going under the assumption, probably a false one, that all
<"parallel" ports that were able to talk to a printer w/ a centronics
<connector, conformed to a standard, and that a parallel zip drive
<needed nothing above and beyond that to work. Of course figuring out how
<to talk to the drive is another story as well.
Severely untrue. PCs use a simple port with little to no hardware
handshaking, however many other use hardware hand shaking so there are
few if any readable lines for data return. Few non pc system implement a
bidirection or EPP port and that is not require to do basic centronics
interface.
Allison
>> Oh, and when I called it an "interpreter," that's a misnomer. It may
look,
>> walk, talk, and smell like an interpreter, but it's actually a JIT
compiler
>> in disguise... that's why it's so darned fast in comparison to an
interpreter.
>
> Actually, it compiles to an internal byte code that can be interpreted
> faster than parsing text, much like Forth or even Java.
In my experience, very few interpreters actually parse text in real time.
Every BASIC I've used AFAIK reduces keywords to byte codes at the time of
entry, and some actually encode numbers etc. at the same time.
Notable exception: I think REXX parses text in real time, or did when I
used it under VM/CMS.
Philip.
At 11:37 PM 1/14/99 -0800, Sam Ismail wrote:
>
>Remember, C has a goto statement, although I don't think in my nearly 10
>years of C programming I've ever used it, although on certain rare
>occasions it seemed the easy way out to a sticky coding problem.
> [...] but C really suffers from a lack of
>a general error trapping mechanism that one can invoke to break out of
>loops as required. Sometimes I think goto's are the answer but I can
>never find an appropriate way to implement it.
I use "goto" in C on a regular and consistent basis for error exceptions:
USHORT firstFunction( void )
{
USHORT lerr;
if ((lerr=secondFunction()) != TE_NOERROR) {
goto out;
}
out:
return lerr;
}
The benefit is that all functions propogate an error code, any
function can fail, and all functions clean up after themselves
after their "out" label.
- John
