20 Sep
2013
20 Sep
'13
5:57 p.m.
So Iwas taking a closer look at the HP 1351A "Graphics Generator" I
have. It's currently in operable condition, except that it won't draw
text (apparently there's something wrong with the character generator,
the :TX commands do nothing at all). I was surprised to discover that
the 1351 (c. 1981) doesn't containa microprocessor or microcontroller of
any kind -- all parsing of the command language it supports is done in
hardware (TTL). (The service manual contains this gem: "The 1351A only
accepts commands listed in this manual and in the Operating and
Programming manual. Any others, especially those mentioned above will
'lock up' the 1351A such that it will have to be re-initialized...")
At any rate, this reminded me of something that I'm prettysure I read
here on cctalk years back, but I can't seem to find any reference toit
anywhere; there was a computer designed at some university that ran an
interpreted language (I'm pretty sure it was BASIC), on the metal-- that
is, much like the 1351A and its vector description language, this
machine's hardware parsed BASIC program text and executed it directly,
rather than implementing some machine language.
Does this ring any bells, or am I insane? (It's quite possible that
both of these things are true...)
- Josh
20 Sep
20 Sep
6:21 p.m.
I suspect it executes HP1351A machine language.
There is no reason a processor can't be implemented
in TTL logic. I have one that is DTL/TTL and it
has a machine language. It definitely runs a machine
language code while running BASIC.
Dwight
Date: Fri, 20 Sep 2013 17:57:11 -0700
From: derschjo at gmail.com
To:
Subject: Hardware parsing of BASIC?
So Iwas taking a closer look at the HP 1351A "Graphics Generator" I
have. It's currently in operable condition, except that it won't draw
text (apparently there's something wrong with the character generator,
the :TX commands do nothing at all). I was surprised to discover that
the 1351 (c. 1981) doesn't containa microprocessor or microcontroller of
any kind -- all parsing of the command language it supports is done in
hardware (TTL). (The service manual contains this gem: "The 1351A only
accepts commands listed in this manual and in the Operating and
Programming manual. Any others, especially those mentioned above will
'lock up' the 1351A such that it will have to be re-initialized...")
At any rate, this reminded me of something that I'm prettysure I read
here on cctalk years back, but I can't seem to find any reference toit
anywhere; there was a computer designed at some university that ran an
interpreted language (I'm pretty sure it was BASIC), on the metal-- that
is, much like the 1351A and its vector description language, this
machine's hardware parsed BASIC program text and executed it directly,
rather than implementing some machine language.
Does this ring any bells, or am I insane? (It's quite possible that
both of these things are true...)
- Josh
25 Sep
25 Sep
1:50 p.m.
In article <BLU178-W39DE4EDF5789DC4D21309AA3230 at phx.gbl>,
dwight elvey <dkelvey at hotmail.com> writes:
I suspect it executes HP1351A machine language.
There is no such thing. It's just a couple of state machines, one for
handling the I/O traffic and producing a display list in RAM and another
for walking the display list to generate a dynamic vector graphic
image.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
20 Sep
20 Sep
7:12 p.m.
On 2013 Sep 20, at 5:57 PM, Josh Dersch wrote:
So Iwas taking a closer look at the HP 1351A
"Graphics Generator" I
have. It's currently in operable condition, except that it won't
draw text (apparently there's something wrong with the character
generator, the :TX commands do nothing at all). I was surprised to
discover that the 1351 (c. 1981) doesn't containa microprocessor or
microcontroller of any kind -- all parsing of the command language
it supports is done in hardware (TTL). (The service manual contains
this gem: "The 1351A only accepts commands listed in this manual
and in the Operating and Programming manual. Any others,
especially those mentioned above will 'lock up' the 1351A such that
it will have to be re-initialized...")
At any rate, this reminded me of something that I'm prettysure I
read here on cctalk years back, but I can't seem to find any
reference toit anywhere; there was a computer designed at some
university that ran an interpreted language (I'm pretty sure it was
BASIC), on the metal-- that is, much like the 1351A and its vector
description language, this machine's hardware parsed BASIC program
text and executed it directly, rather than implementing some
machine language.
Does this ring any bells, or am I insane? (It's quite possible
that both of these things are true...)
Perhaps you're thinking of the Wang 2200, which I'm led to understand
implemented BASIC in microcode; I think it may have been mentioned on
the list a few years ago.
7:43 p.m.
On 9/20/2013 7:12 PM, Brent Hilpert wrote:
On 2013 Sep 20, at 5:57 PM, Josh Dersch wrote:
I recall it being a one-off, experimental sort of thing from the late
60's (where the thesis was something like "compilers and interpreters
are reallyinefficient and will never be as good as machine code, but
what if we did it in /hardware/, well, then...magic.").
I did find a reference to the Fairchild SYMBOL, which seems to be sort
of what I'm describing, but I still don't think it's what I was
originally remembering...
- Josh
So Iwas taking a closer look at the HP 1351A
"Graphics Generator" I
have. It's currently in operable condition, except that it won't
draw text (apparently there's something wrong with the character
generator, the :TX commands do nothing at all). I was surprised to
discover that the 1351 (c. 1981) doesn't containa microprocessor or
microcontroller of any kind -- all parsing of the command language it
supports is done in hardware (TTL). (The service manual contains this
gem: "The 1351A only accepts commands listed in this manual and in
the Operating and Programming manual. Any others, especially those
mentioned above will 'lock up' the 1351A such that it will have to be
re-initialized...")
At any rate, this reminded me of something that I'm prettysure I read
here on cctalk years back, but I can't seem to find any reference
toit anywhere; there was a computer designed at some university that
ran an interpreted language (I'm pretty sure it was BASIC), on the
metal-- that is, much like the 1351A and its vector description
language, this machine's hardware parsed BASIC program text and
executed it directly, rather than implementing some machine language.
Does this ring any bells, or am I insane? (It's quite possible that
both of these things are true...)
Perhaps you're thinking of the Wang 2200, which I'm led to understand
implemented BASIC in microcode; I think it may have been mentioned on
the list a few years ago.
8 p.m.
On 9/20/2013 7:43 PM, Josh Dersch wrote:
On 9/20/2013 7:12 PM, Brent Hilpert wrote:
And now that I read up more on it, I'm pretty sure that my memory of it
being BASIC was faulty, and that the SYMBOL was what I was thinking of
the entire time. Here's a bit of info on it:
http://research.microsoft.com/en-us/um/people/gbell/computer_structures_pri…
Only one was builtand it was used at Iowa State. From the cctalk
archives, it looks like the CHM has whatever remains of it.
- Josh
On 2013 Sep 20, at 5:57 PM, Josh Dersch wrote:
I recall it being a one-off, experimental sort of thing from the late
60's (where the thesis was something like "compilers and interpreters
are reallyinefficient and will never be as good as machine code, but
what if we did it in /hardware/, well, then...magic.").
I did find a reference to the Fairchild SYMBOL, which seems to be sort
of what I'm describing, but I still don't think it's what I was
originally remembering...
- Josh So Iwas taking a closer look at the HP 1351A
"Graphics Generator" I
have. It's currently in operable condition, except that it won't
draw text (apparently there's something wrong with the character
generator, the :TX commands do nothing at all). I was surprised to
discover that the 1351 (c. 1981) doesn't containa microprocessor or
microcontroller of any kind -- all parsing of the command language
it supports is done in hardware (TTL). (The service manual contains
this gem: "The 1351A only accepts commands listed in this manual and
in the Operating and Programming manual. Any others, especially
those mentioned above will 'lock up' the 1351A such that it will
have to be re-initialized...")
At any rate, this reminded me of something that I'm prettysure I
read here on cctalk years back, but I can't seem to find any
reference toit anywhere; there was a computer designed at some
university that ran an interpreted language (I'm pretty sure it was
BASIC), on the metal-- that is, much like the 1351A and its vector
description language, this machine's hardware parsed BASIC program
text and executed it directly, rather than implementing some machine
language.
Does this ring any bells, or am I insane? (It's quite possible that
both of these things are true...)
Perhaps you're thinking of the Wang 2200, which I'm led to understand
implemented BASIC in microcode; I think it may have been mentioned on
the list a few years ago.
21 Sep
21 Sep
12:42 p.m.
So Iwas taking a closer look at the HP 1351A "Graphics Generator" I
have. It's currently in operable condition, except that it won't draw
text (apparently there's something wrong with the character generator,
the :TX commands do nothing at all). I was surprised to discover that
the 1351 (c. 1981) doesn't containa microprocessor or microcontroller of
any kind -- all parsing of the command language it supports is done in
hardware (TTL). (The service manual contains this gem: "The 1351A only
accepts commands listed in this manual and in the Operating and
Programming manual. Any others, especially those mentioned above will
'lock up' the 1351A such that it will have to be re-initialized...")
The earlier HP1350 'Craphics Translator' is similar. It contains no
microprocesosr (which is odd, as HP were certainly using them at the
time). What is (to me) even stranger is that it's essentaily 'random
logic', it is not designed as a processor (built from TTL) or anything
like that. Very odd.
In the 1350, the chracter geenrator is sepeaate daughterboard, the unit
will work without it, but obviously can't then handle text comands. It's
been some time since I've been inside my 1350, but from what I rememebr
the chracter generator is a lookup table of vectors todraw each chracter
(unlike the DEC VT11, say, which scans a little raster at each chracter
location and uses a conventioal bitmapped chracter generator ROM).
At any rate, this reminded me of something that I'm prettysure I read
here on cctalk years back, but I can't seem to find any reference toit
anywhere; there was a computer designed at some university that ran an
interpreted language (I'm pretty sure it was BASIC), on the metal-- that
is, much like the 1351A and its vector description language, this
machine's hardware parsed BASIC program text and executed it directly,
rather than implementing some machine language.
Depends on what you mean by 'on the metal'. There have been several
machines that interpret high-level languesesa at the microcode level, I
think Wang made one for BASIC. But I've never heard of a non-microcoded
machine that did that. Was there one?
-tony
22 Sep
22 Sep
1:19 a.m.
On 9/21/2013 12:42 PM, Tony Duell wrote:
Right, at first I thought it might be a simple custom CPU of some sort,
but looking at the schematics (and the *very* detailed explanations in
the service manual) made it clear that it's basically a huge state
machine for parsing command text.
Yeah, not BASIC (I had misremembered) but the Fairchild SYMBOL (mid-late
60s) essentially had a compiler implemented in hardware for a
programming language (called SYMBOL); effectively it executed program
text directly. There's a bit of info here:
http://research.microsoft.com/en-us/um/people/gbell/computer_structures_pri…
I want to track down more documentation on the language, there doesn't
seem to be a great deal of information currently available about it.
The above book makes reference to a publication "[Chesley and Smith,
1971]" that looks to be a good source of information. Going to have to
dig that one up.
- Josh
So Iwas taking
a closer look at the HP 1351A "Graphics Generator" I
have. It's currently in operable condition, except that it won't draw
text (apparently there's something wrong with the character generator,
the :TX commands do nothing at all). I was surprised to discover that
the 1351 (c. 1981) doesn't containa microprocessor or microcontroller of
any kind -- all parsing of the command language it supports is done in
hardware (TTL). (The service manual contains this gem: "The 1351A only
accepts commands listed in this manual and in the Operating and
Programming manual. Any others, especially those mentioned above will
'lock up' the 1351A such that it will have to be re-initialized...")
The earlier HP1350 'Craphics Translator' is similar. It contains no
microprocesosr (which is odd, as HP were certainly using them at the
time). What is (to me) even stranger is that it's essentaily 'random
logic', it is not designed as a processor (built from TTL) or anything
like that. Very odd.
In the 1350, the chracter geenrator is sepeaate daughterboard, the unit
will work without it, but obviously can't then handle text comands. It's
been some time since I've been inside my 1350, but from what I rememebr
the chracter generator is a lookup table of vectors todraw each chracter
(unlike the DEC VT11, say, which scans a little raster at each chracter
location and uses a conventioal bitmapped chracter generator ROM).
Yeah, that's what it looks like from the manuals. I haven't had time
yet to debug anything (still distracted with the 8/L and my lack of
spare time...). Hopefully it's not too hard to track down. I have
played with it a bit (hooked up to an HP-87 and a Tek 608B X/Y display)
and it's pretty fun.
At any rate, this reminded me of something that
I'm prettysure I read
here on cctalk years back, but I can't seem to find any reference toit
anywhere; there was a computer designed at some university that ran an
interpreted language (I'm pretty sure it was BASIC), on the metal-- that
is, much like the 1351A and its vector description language, this
machine's hardware parsed BASIC program text and executed it directly,
rather than implementing some machine language.
Depends on what you mean by
'on the metal'. There have been several
machines that interpret high-level languesesa at the microcode level, I
think Wang made one for BASIC. But I've never heard of a non-microcoded
machine that did that. Was there one?
-tony
3:58 p.m.
From: derschjo at gmail.com
Right, at first I thought it might be a simple custom CPU of some sort,
but looking at the schematics (and the *very* detailed explanations in
the service manual) made it clear that it's basically a huge state
machine for parsing command text.
I find that interesting that it would not be considered a CPU.
After all, that is all a CPU does. It would seem that the only
difference was that most CPUs encrypt the instructions.
It sure sounds like a CPU to me.
It is a state machine that executes based on decoding
input.
I'm not sure that the input has to be some special binary
code and can't be directly decoded text to qualify as
a CPU.
Dwight
4:06 p.m.
On Sun, Sep 22, 2013 at 4:58 PM, dwight elvey <dkelvey at hotmail.com> wrote:
If you broaden the definition of CPU like that, is there any kind of
sequential logic (state machine) that you would NOT consider to be a CPU?
From: derschjo
at gmail.com
it's basically a huge state
machine for parsing command text.
I find that interesting that it would not be considered a CPU.
After all, that is all a CPU does. It would seem that the only
difference was that most CPUs encrypt the instructions.
It sure sounds like a CPU to me.
4:13 p.m.
On 9/22/2013 3:58 PM, dwight elvey wrote:
Well, it's a processor of a sort, but it's not what I'd consider a
typical CPU; it offers noflow control or logical operationsand does no
computation. What it does do is parse incoming text streams and convert
that text into data thatgets stuffed into memory. (It also has logic to
walk through that memory and draw vectors based on the contents). So
it's an external display list + display processor, but it's not what
fits a typical definition of a CPU.
- Josh
From: derschjo
at gmail.com
Right, at first I thought it might be a simple custom CPU of some sort,
but looking at the schematics (and the *very* detailed explanations in
the service manual) made it clear that it's basically a huge state
machine for parsing command text.
I find that interesting that it would not be considered a CPU.
After all, that is all a CPU does. It would seem that the only
difference was that most CPUs encrypt the instructions.
It sure sounds like a CPU to me.
It is a state machine that executes based on decoding
input.
I'm not sure that the input has to be some special binary
code and can't be directly decoded text to qualify as
a CPU.
Dwight
23 Sep
23 Sep
12:06 p.m.
From: derschjo at gmail.com
=20
Right, at first I thought it might be a simple custom CPU of some sort,=20
but looking at the schematics (and the *very* detailed explanations in=20
the service manual) made it clear that it's basically a huge state=20
machine for parsing command text.
=20
I find that interesting that it would not be considered a CPU.
After all, that is all a CPU does. It would seem that the only
difference was that most CPUs encrypt the instructions.
It sure sounds like a CPU to me. It is a state machine that executes based on decoding
input.
I'm not sure that the input has to be some special binary
code and can't be directly decoded text to qualify as
a CPU.
A device that reads ASCII-encoded instructions from memory and executes
them is a CPU. But that's not the HP1350.
Incidentally, it's also hard to distinguish between a 'microcoded control
system' and a 'state machine' in some cases. Or between a 'microcoded
processor execting a program' and a 'RISC processor running an
instruction interpretter that executes a program'
-tony
22 Sep
22 Sep
7:23 p.m.
On Sun, 22 Sep 2013, Josh Dersch wrote:
[...much text skipped...]
Yeah, not BASIC (I had misremembered) but the Fairchild SYMBOL (mid-late 60s)
essentially had a compiler implemented in hardware for a programming language
(called SYMBOL); effectively it executed program text directly. There's a bit
of info here:
http://research.microsoft.com/en-us/um/people/gbell/computer_structures_pri…
I want to track down more documentation on the language, there doesn't seem to
be a great deal of information currently available about it. The above book
makes reference to a publication "[Chesley and Smith, 1971]" that looks to be
a good source of information. Going to have to dig that one up.
- Josh
There's a nice, short, IEEE article:
Fairchild Symbol Computer
Stanley Mazor, Anne Fitzpatrick
IEEE Annals of the History of Computing, Volume 30, Number 1,
January-March 2008, pp. 92-95 (Article)
at:
http://muse.jhu.edu/journals/ieee_annals_of_the_history_of_computing/v030/3…
or, as two lines to be joined:
http://muse.jhu.edu/journals/
ieee_annals_of_the_history_of_computing/v030/30.1mazor.pdf
--Ernest
5:31 p.m.
Josh D. wrote:
At any rate, this reminded me of something that
I'm pretty sure I read
here
on cctalk years back, but I can't seem to find any
reference to it
anywhere;
there was a computer designed at some university that
ran an
interpreted
language (I'm pretty sure it was BASIC), on the
metal-- that is, much
like the
1351A and its vector description language, this
machine's hardware
parsed
BASIC program text and executed it directly, rather
than implementing
some
machine language.
The Wang 2200 executed BASIC directly, though it was a microcoded engine
that did the execution.
If you consider a microcoded processor that accepts BASIC statements and
tokenizes them on input, and executes the tokenized code when the BASIC
program is run a "hardware" implementation of BASIC, then this probably
fits the criteria of the posting above.
The 2200 was a descendent of the Wang 700-series advanced programmable
calculators. The microcode engine in the 2200 was more streamlined and
efficient than that used in the calculators (and implemented with
slightly higher-levels of integration than the 700-series calculators),
but the basic concepts of how the microcode engine operated was similar
to that used in the calculators. The original concept that became the
Wang 700 calculators was actually to be a computer that was supposed to
compete with IBM, but when Dr. Wang learned of HP's 9100A calculator
coming to market, and Wang's main cash cow was its 300-series
calculators, Dr. Wang quickly repurposed the design of the computer to
become a high-end calculator to compete with HP's amazing machine.
As Dr. Wang realized that the electronic calculator marketplace would
soon be owned by the chip makers, he resurrected the idea of building
low-cost computer, re-using the concepts of the calculators, and that
became the Wang 2200.
Jim Battle has a great site outlining Wang's 2200-series "personal"
computers at www.wang2200.org. He has a emulator that executes the
microcode to provide a faithful emulation of the Wang 2200 computer.
Rick Bensene
7:35 p.m.
On 9/22/2013 6:31 PM, Rick Bensene wrote:
The Wang 2200 executed BASIC directly, though it was a
microcoded engine
that did the execution.
If you consider a microcoded processor that accepts BASIC statements and
tokenizes them on input, and executes the tokenized code when the BASIC
program is run a "hardware" implementation of BASIC, then this probably
fits the criteria of the posting above.
But did not the classic computers, in the late 50's plan for the very
same idea, with true stack based languages using logic gates rather than
microcode. Getting side tracked with time sharing, is what gave us Basic
in my view. Ben.
7:49 p.m.
Although, not what your thinking of, there were several
Forth engines made.
Most of the low level words were single instructions.
In fact many low level words were often combined
as single instructions.
It still needed the string interpreter for interactive
but compiled was mostly values that translated
direct to execution.
Dwight
Date: Sun, 22 Sep 2013 20:35:14 -0600
From: bfranchuk at jetnet.ab.ca
To: cctalk at classiccmp.org
Subject: Re: Hardware parsing of BASIC?
On 9/22/2013 6:31 PM, Rick Bensene wrote:
The Wang 2200 executed BASIC directly, though it
was a microcoded engine
that did the execution.
If you consider a microcoded processor that accepts BASIC statements and
tokenizes them on input, and executes the tokenized code when the BASIC
program is run a "hardware" implementation of BASIC, then this probably
fits the criteria of the posting above.
But did not the classic computers, in the late 50's plan for the very
same idea, with true stack based languages using logic gates rather than
microcode. Getting side tracked with time sharing, is what gave us Basic
in my view. Ben.
8:06 p.m.
On 09/22/2013 07:49 PM, dwight elvey wrote:
Although, not what your thinking of, there were
several
Forth engines made.
Most of the low level words were single instructions.
In fact many low level words were often combined
as single instructions.
It still needed the string interpreter for interactive
but compiled was mostly values that translated
direct to execution.
Western Digital had the WD90 that implemented P-code. But again, just
P-code and not a lexical parser/compiler per se.
There's an exceedingly fine line between firmware and microprogramming.
--Chuck
8:46 p.m.
On 22/09/13 10:49 PM, dwight elvey wrote:
Although, not what your thinking of, there were
several
Forth engines made.
Most of the low level words were single instructions.
In fact many low level words were often combined
as single instructions.
It still needed the string interpreter for interactive
but compiled was mostly values that translated
direct to execution.
One could also mention the Inmos Transputer, which had a (shallow) stack
oriented instruction set.
The Transputer is architecturally interesting from many angles, as is
mentioned on this list from time to time.
--Toby
Dwight
Date: Sun, 22 Sep 2013 20:35:14 -0600
From: bfranchuk at jetnet.ab.ca
To: cctalk at classiccmp.org
Subject: Re: Hardware parsing of BASIC?
On 9/22/2013 6:31 PM, Rick Bensene wrote:
The Wang 2200 executed BASIC directly, though it
was a microcoded engine
that did the execution.
If you consider a microcoded processor that accepts BASIC statements and
tokenizes them on input, and executes the tokenized code when the BASIC
program is run a "hardware" implementation of BASIC, then this probably
fits the criteria of the posting above.
But did not the classic computers, in the late 50's plan for the very
same idea, with true stack based languages using logic gates rather than
microcode. Getting side tracked with time sharing, is what gave us Basic
in my view. Ben.
8:04 p.m.
On 09/22/2013 07:35 PM, ben wrote:
But did not the classic computers, in the late
50's plan for the very
same idea, with true stack based languages using logic gates rather than
microcode. Getting side tracked with time sharing, is what gave us Basic
in my view. Ben.
Are you perhaps referring to the Burroughs B5000 and succeeding machines
of the line? While it's true that they were pretty much ALGOL-60
machines, you still needed a frontend to do lexical parsing.
Are there random-logic lexical parsers?
--Chuck
9:21 p.m.
On 9/22/2013 9:04 PM, Chuck Guzis wrote:
On 09/22/2013 07:35 PM, ben wrote:
While those machines, are close to what I was thinking of,the concept
of generic high level languages was to be the next level with a common
run time code.
But did not the classic computers, in the late
50's plan for the very
same idea, with true stack based languages using logic gates rather than
microcode. Getting side tracked with time sharing, is what gave us Basic
in my view. Ben.
Are you perhaps referring to the Burroughs B5000 and succeeding machines
of the line? While it's true that they were pretty much ALGOL-60
machines, you still needed a frontend to do lexical parsing. Are there random-logic lexical parsers?
Had they standardized on I/O I don't see why would not have been
possible. A keyword shift key, with tokens directly input from the
console or punch card encoding.
--Chuck
4106
days inactive
4110
days old
19 comments
11 participants
participants (11)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
derschjo＠gmail.com -
dkelvey＠hotmail.com -
eallen＠owt.com -
hilpert＠cs.ubc.ca -
legalize＠xmission.com -
rickb＠bensene.com -
spacewar＠gmail.com -
toby＠telegraphics.com.au