>
>Subject: Re: Infocom on PDP-11
> From: Paul Koning <pkoning at equallogic.com>
> Date: Sun, 08 May 2005 19:10:08 -0400
> To: cctalk at classiccmp.org
> Cc:
> woodelf> The lack of local variables makes C very dificult.
>
>Huh?
That is really just convention. I can't see why it's relevent.
>You're confusing the lack of a hardware stack with the lack of local
>variables. They are not at all related.
Correct. But a stack makes some forms of programming easier.
>The IBM 360/370 series doesn't have a stack, and some of its
>restrictions are vaguely PDP-8 like. Nevertheless, GCC supports C
>(and C++) quite nicely on those machines.
IBM360 like a PDP-8???? Explain please.
>For that matter, Algol had local variables long before C was invented,
>and as you pointed out, there's an Algol for the PDP-8. (Then again,
>that's not a true compiler -- it compiles to an intermediate form that
>looks very much like a subset of the Burroughs 5500 instruction set.)
Using an IL was a way of making the complier easier I'd guess.
Compiler deign has become more sophisticated since.
>And Unix originally appeared on the PDP-7, which you can describe
>quite reasonably as an 18-bit superset of the PDP-8. (That's
>historically nonsense, but as a description it fits.)
In many ways it's pretty close. PDP-8 and PDP-7 had more
similar than different. Same for The PDP-1 and 5 that preceded both.
The PDP6 and 11 were departures as was VAX. The departures were
PDP-6,11 and VAX are very CISC in the vax case, to the extreme.
>Did C exist
>back then, or did that wait until Unix was ported to the PDP-11? I
>don't know.
NO, PDP-11 was the first occurance for C. After that it was
ported to Honeywell6000 and the Interdata 8/32 and even the
IBM System/370. The native language for unix on PDP-7 was
B and it's influence was from BCPL. The introduction of PDP-11
was early in the life of the machine to Bell Labs and K&R were
quick to take the bare iron and endevor to put all their previous
work on the -11 to make it useful.
A lot of the register,
local variable and addressing conventions directly reflect the
PDP-11 hardware, instruction set and native addressing modes
under C.
>Finally, CDC 6000s don't have a stack either, but the first Pascal
>compiler ran on that machine. Implementing a stack on a non-stack
>machine (or non-stack language like Fortran-II) is a nice elementary
>Exercise for the Student.
Be very careful what you call a stack or not. The PDP-8 (Straight 8)
has no hardware stack but, it has autoindex registers that are very handy
for stack implmentation. It's also not hard to store a return address
elsewhere to implement subroutine recursion. Later PDP-8a and the 6120
chip versions had a real hardware stack added. The stacks were
implemented using IOTs so it was possible to add them to any -8. The
lack of a return stack doesn't mean there isn't a set of addressing
modes to implement a software stack from all the minis and micros
I've seen.
Allison
I'm surprised no one has mentioned the Mona Lisa prints. The I/O room
at MSU's Computer Center had a large image generated by scanning a
photo of the painting. A scheme was worked out of which characters
(multiples in some cases) were drawn in any given cell to add up
to the appropriate darkness. I believe it was actually output to a
plotter which took a substantial amount of time to complete the job.
I would have guessed most large centers would have had such things.
On a more personal note, in the 1985-86 time frame I was working for
a software outfit that did real estate systems. The R&D wizard there
built hardware which went into standard serial terminals (Esprit
6310's; can't recall if there was ever a version in the TeleVideo
925's) to display 4 bit images of homes. The card worked by going
into the video chain of the terminal to overlay images, and into the
serial chain to grab bits. It was not intelligent; simply a marble
machine which recognized a specific introductory escape sequence and
then clocked nibbles into its video ram. The images were taken with
Sony cameras which wrote them to 2" floppies. I think the storage
may have been analog video, actually. They were then digitized using
a video frame grabber board in a standard PC and uploaded to the host.
In addition to screen display, we did MLS books with the images
integrated, etc. The output was generally done on Printronix P-300
printers, which were dot-addressable. (For those who haven't
met one of these machines, they had a shuttle with 132 "pixel"
hammers. The shuttle would work from left to right stopping at 8
or so positions. The hammers would print the top row of dots in
the characters of the current line, then the paper would move up one
"raster" line and the shuttle would run right to left doing the next
row. Eventually one row of characters would be completely printed.
A P-300 could print about 300 lines per minute. The shuttle and the
many print hammers gave the printers a distinctive sound. In addition
to the all-points-addressable mode, you could build or buy custom
ROMs with special characters in them.)
A few of us went into the office one weekend evening shortly after the
"Live Aid" concert with a video tape of the show, and grabbed and
printed a fair number of images from the performances. The 4-bit
graphics made interesting work of lens stars from the stage lighting.
De
Hi folks,
Having repaired my GIGI power supply and found my local copy of the user and
techical manuals (big TIFs, I'm assuming there are tools available to let me
convert these to PDFs?) I notice that while the manuals explicitly mention
the Barco GD33 and 'monochrome monitors' they also mention 'other commercial
color monitors.
This begs questions that I can't try since I don't have the appropriate
cables here yet, but has anyone used a GIGI on the likes of the VRT19 (19"
RGB sync-on-green with 75 ohm switches like the GD33), VR262 (composite
mono) and indeed the retro collector's friend the Philips CM8833 composite
colour?
TIA!
--
Adrian/Witchy
Creator/Curator of Binary Dinosaurs, quite probably the UK's biggest private
home computer collection.
www.binarydinosaurs.co.uk - the online museum
www.aaghverts.co.uk - *the* site for letting you moan about adverts!
www.snakebiteandblack.co.uk - former gothic shenanigans :(
>
>Subject: Re: 'goto" gone from computer languages or is it!
> From: "Randy McLaughlin" <cctalk at randy482.com>
> Date: Wed, 11 May 2005 22:04:53 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>Goto's can be bad if they make the code hard to follow but I find that most
>people write such sloppy code that it's hard to follow anyway as well as
>making code more complicated trying to avoid goto's.
Basic is a language that is easy to code badly.
I'm one of the few that was mostly BASIC and ASM until UCSD P-system
and decided to learn a "structured" language. I was eye opening the
difference coding learned. After that I tried writing basic using
block structure and treating goto and return like Call and JUMP with
better looking results. I can see the effect it had looking at some
of my really old code.
I agree with an earlier post. BASIC improperly can rot your mind,
it's bad drugs for programmers.
Allison
>
>Subject: Re: 'goto" gone from computer languages or is it!
> From: John Foust <jfoust at threedee.com>
> Date: Thu, 12 May 2005 13:15:11 -0500
> To: cctalk at classiccmp.org
>
>At 12:56 PM 5/12/2005, Allison wrote:
>>Often reading it is the challenge. Goto within a subroutine
>>usually reads fine. Its when there are subs within Loop/whiles
>>get mixed with gotos.
>
>Even BASIC has a call stack that will eventually overflow.
>
However, GOTO is not a CALL. GOSUB can kill the stack.
Allison
>From: "Allison" <ajp166 at bellatlantic.net>
>
>>
>>Subject: Re: 'goto" gone from computer languages or is it!
>> From: "Dwight K. Elvey" <dwight.elvey at amd.com>
>> Date: Thu, 12 May 2005 10:37:19 -0700 (PDT)
>> To: cctalk at classiccmp.org
>>
>>Hi
>> I'd suspect that most didn't like the goto
>>because it becomes hard to implement in a structured
>>language. Things like random nesting of subroutines and
>>then goto's to various points can make things really
>>messed up. There are also the problems of allocated
>>memory. Do you keep it or clean it?
>
>Often reading it is the challenge. Goto within a subroutine
>usually reads fine. Its when there are subs within Loop/whiles
>get mixed with gotos. It's more about readability. Old basic
>was bad as often people were also cramped for space (especially
>interpreted basics.).
>
>> Many think of goto as being similar to jmp in assembly.
>
>It is.
>
>>Actually in a high level language, it is more complicated
>>than that. The language tend to lead one to think they
>>can use it just anywhere. In assembly, you are more
>>conscious ( or should be ) of thing like stack depth
>>and allocated space, since you explicitly handle these
>>things.
>
>You seem to confuse JMP/Jump/goto with Call/JMS/GOSUB as only
>the latter affects the stack (in asm).
Hi
I have no confusion, I meant that jmp instruction does
not effect the stacks, for good or bad. It is that most
high level languages hide the stack actions giving
the false impression that one can goto anywhere. In
assembly, one keeps track of such stuff themselves
so they don't get into such trouble.
>
>In assembly you often have jumps as a result of branch conditions
>In some cpus the logic is actully skip next instuction on condition.
>in basic the conditional is IF xx then Goto YYYY (some allow operations.).
>The computed goto is only a replacement for SWITCH or IF THEN trees
>and a improvement over the latter.
else is a jmp. A computed goto is usually done from a table
lookup in assembly although I've seen it done directly for
interupt vectors.
Dwight
>
>In the end GOTO is not bad, it is random stringy pasta code that can
>result from misuse.
>
>
>Allison
>
>
I recently picked up some memory boards for which I have no manuals.
If anyone has documentation for these and will loan the hard copy to me, I
will scan the manuals to PDF files and make them available on Howard's site,
and return the originals. Of course if anyone has a scanned version in any
format, that works also.
There are two boards:
-"Thinker Toys" (Morrow) 32K Superram S-100 memory board, (c)1978. Board
has 64 type 4044 or 5257 4kx1 static memory chips
-"Thinker Toys" (Morrow) 16K Superam S-100 memory board, (c) 1978. Board
has 32 type 2114 memory chips (are these and the 4044/5257 all
interchangeable?). Board has six 8-position dip switches on it, plus an 8
position jumper. Even allowing for both bank switching and 24-bit
addressing, it seems like a lot.
Thanks,
Barry Watzman
Watzman at neo.rr.com
>
>Subject: Re: 'goto" gone from computer languages or is it!
> From: Vintage Computer Festival <vcf at siconic.com>
> Date: Thu, 12 May 2005 10:26:41 -0700 (PDT)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Again, I swore off Pascal because of the UCSD system. If I'd had Turbo
>Pascal to learn on then things might've turned out much different. Of
>course, Turbo Pascal required a CP/M card and a license. It was easier
>for teacher to just copy UCSD Pascal ;)
Depends on the boxen used and it's storage limits. I had a NS* with
three 89k drives and that was adaquate to avoid swapping media. In
the end it was ok. Though it beat the Univac1180, greatly. The reason
was I was developing code infront of a H19 terminal with an anadex 80cps
printer rather than submitting card decks. My intro to Pascal in '79
was a Data Structures course with asm and BASIC as a "what I had before".
>Pascal is not a bad language to develop in. But I much prefer the
>succinctness of C.
Pascal is OK. C on the other hand I found had some syntax odditites
that still trips me. I find C is like reading weather sequence reports
for the first time. I'll repeat that in that form. I fnd C rd wx sq rpts
trbl. It's often cryptic to the extreme and nearly as readable as
uncommented ASM. The OO versions are plainly pain.
Allison
>
>Subject: Re: Infocom on PDP-11
> From: Eric J Korpela <korpela at gmail.com>
> Date: Tue, 10 May 2005 15:50:02 -0700
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>The C data types only have minimum sizes. Actual sizes are up to the
>implementation.
>The resulting C data types for a PDP-8 would be 12-bit char, 24 bit
>short and int, 36 bit long. As long as limits.h contains the correct
>values and the sizeof() operator correctly returns 1, 2 and 3 for the
What about byte as in 6bits. Thats a valid item for PDP-8 as one
intruction BSW swaps accumulator halfs. Also much of the character
IO was 6bit.
>Don't ask me to write the floating point library, though...
Don't have to as there was a good asm one supplied with the machine. ;)
Allison
