Anyone out there have a Tek 4109 terminal, better still with manuals,
and even better still with service info?
Witchy chucked his one this way last night. It's powering up now, which
is a start...
... sometimes it powers up to just a blank screen, sometimes to a screen
with just a flashing cursor (possibly that's right behaviour :) and
sometimes a blank screen along with a flashing caps-lock LED.
On a reset, sometimes it gives a blank screen and two long beeps from
the speaker.
Anyone able to tell me what the beep codes mean, what the flashing caps
LED means, and what the default power-up state should be?
Possibly it's waiting for something from a host (yuck), or at least
indication that it's connected to a host via serial port control lines -
but the varying power up / reset states suggests that it's not entirely
happy anyway...
Oh, confirmation that it has all its ROMs would be nice. Of the two rows
of four columns, the leftmost column is empty - is that OK, or has
someone swiped those two chips for something else? Presumably the fact
that it has 6 ROM chips in place (and they're externally accessible and
obviously designed to be pluggable) hints that it has some sort of
custom on-board app?
There's a Tek tablet with it too (4197 IIRC) - no idea which of the two
COM ports this should plug into, but I'd assume if the terminal was
going to do anything it'd do it whether the tablet was present or not...
anyone? :)
cheers
Jules
>> Even BASIC has a call stack that will eventually overflow.
> On a 6502 (PET, Apple II...) it's not that deep because of
> the 1-page stack. ISTR about 5 levels of GOSUBs were possible
> before you ran the risk of stack overflow, but it might have
> been as deep as 8.
Assuming the stack is cleared by RUN then you can nest 40 to
50 levels of GOSUBs in most 6502 BAISCs.
FOR ... NEXT is the stack hog, you can usually only nest that
15 deep or less.
With C= BASIC you have lass room as the top 10 bytes or so of
the stack are reserved for float to ASCII conversion.
Lee.
.
___________________________________________________________
Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com
Whoa dude, how could you forget J. Willard Gibbs? I know, brain entropy.
Available in post offices "nationwide" (offer only good in the US)
Meanwhile, back at epay:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=1247&item=5196808330…
He's right --- it's a Alto Hawley mouse. The boards I recognize are the
Alto CRAM board and also the Alto MOS memory board.
The rest of the boards are wirewrap prototypes of something, but what is
the question.
And, the price is only $2K-$1.01; what a bargain.
I have quite a few of these. 3.5" form factor. If anyone needs them let me
know. You just pay for shipping plus pay pal fees from New Jersey. Most are
New In Box units. I also have the appnotes.
Kelly
>
>Subject: Free for pickup: hotrod kaypro [Austin, TX, USA]
> From: Jim Battle <frustum at pacbell.net>
> Date: Fri, 13 May 2005 13:30:35 -0500
> To: cctalk at classiccmp.org
>
>Start with a Kaypro II.
>
>It has a modification to run at 5.0 MHz as well as the standard 2.5 MHz.
>
>One of the floppies has been replaced with a hard drive, partitioned as
>drives A/B/C/D. The remaining floppy is drive E. I have the original
>floppy that was displaced by the hard drive.
>
>It has been modified to have a fan.
>
>It has a RAM disk installed in it as well.
>
>It sports the Advent Turborom.
Sounds like my 4/84! Rather than a hard disk I used a 3.5" floppy
internal and one in the 5.25 slot via an adaptor along with the HH
5.25 48tpi for compatability. I alsohave the Advent turborom with
the personality card so it knows 96tpi 80tr DSdd. Plus mine has
the handyman rom/ piggyback board with RTC. Sweet machine to use
and tote around for effect.
Allison
>
>Subject: Anyone playing with the 8x300
> From: "Dwight K. Elvey" <dwight.elvey at AMD.com>
> Date: Fri, 13 May 2005 14:29:31 -0700 (PDT)
> To: cctalk at classiccmp.org
>
>Hi
> I'm looking at an application of the 8X300 by
>Signetics. This is for a hard disk controller.
>Is anyone fiddling with simmulators for this processor.
>It seems like someone was a while back.
> My current application is on an Olivetti M20 not
>a TRS80.
>Dwight
>
Ah the classic first of the fast microcontrollers.
I'd have to dig but I vaguely remember the 8x300
as a disk controller apnote. Nasty beast to program.
Allison
Hi
I can think of at least one that might
do something funny in Forth. Example:
: DoSomething
20 0 DO
R> 1+ >R
I .
LOOP ;
Still, execution order is well defined. This operation
will do different things based on the Forth it
was used with but the order of doing things is
not under question.
It might even crash the computer. This kind of thing
is usually specified to not be covered by the specifications
in most Forth standards. Usually, the release does
specify the behavior in any case.
Dwight
>From: "Dave Dunfield" <dave04a at dunfield.com>
>
>>> I think the OP's point has been completely missed (that a valid program is a
>>> inherently very definitive and detailed specification).
>>
>> What I was commenting on was this statement by John Hogerhuis:
>>
>>> I think the programming language is the most
>>> succinct, clear, and unambiguous specification language imaginable.
>>> Almost always each construct has one and only one interpretation.
>>
>> Which really depends upon the language.
>
>I agree with his statement - however in a public forum, one needs to add
>some fire resistant padding like "programming language when properly used"
>or "a valid program". C like many languages (including FORTH :-) has loopholes
>where one can create program which invoke undefined behaviour, however these
>constructs generally exist in the real world only at the hand of someone very
>new to the language, or intentially contriving an "example".
>
>Generally speaking, a programming language is more succinct, clear and
>unambiguous than many other forms of abstraction - the fact that it is possible
>to abuse it to other ends in specific cases does not invalidate that claim.
>
>
>> -spc (And C leaves some stuff underspecified like this to help compiler
>> writers wring performance out of compiled code ... )
>
>and for historical reasons.
>
>Regards,
>Dave
>--
>dave04a (at) Dave Dunfield
>dunfield (dot) Firmware development services & tools: www.dunfield.com
>com Collector of vintage computing equipment:
> http://www.parse.com/~ddunfield/museum/index.html
>
>
>
I have finally managed to schedule a rescue near my house, a Data
General Nova 4 in a 5' blue DG rack. It's a one-owner system, bought
20+ years ago as a general purpose office computer for a machine shop
north of town. Unfortunately, the owner pitched out everything except
the rack and rack contents, several years ago. I haven't looked yet,
but I suspect that there's stuff to be found on bitsavers.
-ethan
At 12:42 13/05/2005 -0700, you wrote:
>Point taken; my first guess was 0 0 0, but it is apparently left
>ambiguous by the standards committee. I did use the term "almost
>always" to hedge, but still, you're right.
>
>Nevertheless, for any given compiler there is only one interpretation.
>So I hereby clarify my statement to say that programming languages as
>implemented by actual compilers or interpreters are the most succinct,
>clear and unambigious specification languages imaginable.
Now I disagree with you - if you rely on a particular implementations
handling of undefined behaviour, your abstraction is no longer clear
or unambiguous - in fact, quite the opposite...
The only correction to be made to your original statement, is that
the programming language must be used correctly - an idea that I
automatically assumed from the beginning, hence I originally had
nothing to add to it.
>To another poster's point about "overspecification," I guess that's
>true. So? That's what comments and thoughtful use of identifiers is
>for.
... and avoid undefined bahaviour ...
>Sorry my first couple of posts on the list are to OT threads. I'll try
>to do better in the future :-)
[I've seen worst OT go on a lot longer :-]
but yeah - this is getting to far away from where we should be - time to
go down to the basement and blink some lights!
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
>> I think the OP's point has been completely missed (that a valid program is a
>> inherently very definitive and detailed specification).
>
> What I was commenting on was this statement by John Hogerhuis:
>
>> I think the programming language is the most
>> succinct, clear, and unambiguous specification language imaginable.
>> Almost always each construct has one and only one interpretation.
>
> Which really depends upon the language.
I agree with his statement - however in a public forum, one needs to add
some fire resistant padding like "programming language when properly used"
or "a valid program". C like many languages (including FORTH :-) has loopholes
where one can create program which invoke undefined behaviour, however these
constructs generally exist in the real world only at the hand of someone very
new to the language, or intentially contriving an "example".
Generally speaking, a programming language is more succinct, clear and
unambiguous than many other forms of abstraction - the fact that it is possible
to abuse it to other ends in specific cases does not invalidate that claim.
> -spc (And C leaves some stuff underspecified like this to help compiler
> writers wring performance out of compiled code ... )
and for historical reasons.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
