>From: "Jim Battle" <frustum(a)pacbell.net>
>
>Dwight K. Elvey wrote:
>...
>> In any case, I never understood the stigma of using self
>> modifying code. It does require careful documentation if
>> it is expected to be maintained. There is no reason why
>> it can't be as robust as any other code if done properly.
>> I suspect it was used as a sales talk when someone was
>> trying to pitch their version of code to be better than
>> someone else's. Such things as overlays would qualify as
>> more risky uses of self modifying code but that is done
>> without mention.
>
>Obvious drawbacks --
>
>doesn't work if you ROM the code
>
>indeterminate behavior on certain chips that have instruction caches.
>the data cache snoops and invalidates the write address, but the
>instruction cache doesn't snoop and so requires an explicit flush (eg,
>the i860).
>
>even if the icache snoops the write, it can have a performance impact
>depending how often the code is modified since it can result in a full
>instruction pipe flush.
>
>even without caches, there can be a race between the data being written
>and the instruction fetch path. some self modifying code that works
>reliably on a 386 may not work on a 486.
>
>in an interrupt driven environment, such code is unlikely to be
>reentrant/thread safe/interrupt safe.
>
>it is harder to maintain.
>
>but, I agree, sometimes a coder has to do what a coder has to do.
>
>
Hi
I should have mentioned the issues with instruction caches
and pipelines. After all, our K8 is heavy into this. I was
thinking more in terms of small micros or even in the case
where there is a well defined cache that can be used to advantage.
Anytime one does something out of the ordinary, one needs
to make it clear all of the restrictions and such of how
it is to be used. One of the examples of how a known cache
can be to advantage is like the adsp2100 works. It has a 6
instruction cache so that it can do things like over write
the current instructions in memory for an overlay while
running the loader code from the cache. It does need the
interrupts disabled but this can be handy for something
like a flash update.
Dwight
Hey, all:
I'm meeting the nicest people lately. :) I've run into someone who
has a DEC Pro 350 which he'd like to sell to a respectful owner. Here's
his description of the system:
> DEC Pro-350 (circa fall 1983)
> 10GB drive
> 2 400K floppies (400K each? 800K each? now I don't remember)
> VT-220 style keyboard and display
> hang-on copyholder for the monitor
> vertical stand for the system unit
> all P/OS diskettes and manuals
> RSX-11M disks and manuals (some are copies)
> Original boxes (unsure of the condition)
>
> LA-100PC printer
> extra ribbons (if I can find them) - reinkable
> some rom cartridges including Epson MX-80 emulation (again - if I can
> find them)
> no box - sorry
>
> The BIOS battery is probably dead by now, but it's 3 AAA nicads if I
> remember. Other than that, it's ready to go.
I found it an encouraging sign that he regretted not having the original
printer box. :) Anyway, anyone who has an interest and/or questions
and/or offers can contact the owner directly. His name's Ron Hansen, his
e-mail is <ogre(a)brainlink.com>, and from the e-mails we've exchanged he
sounds like a nice guy. :)
Thanks!
-O.-
Message: 16
Date: Sat, 11 Oct 2003 09:04:11 -0400
From: Ian Primus <ian_primus(a)yahoo.com>
Subject: Re: ASR33 Teletype interfacing
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
Message-ID: <67FFB9E5-FBEB-11D7-86CD-000393D7845A(a)yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
I am late in an response to this ASR33 discussion but the comments here
definitely hit some memory banks buried deep.
In the early 70's, I recall that 120VDC was the source for 60ma current
loop to teletype, and it seems to me that "full-duplex" had the send
side sourced from the teletype and the receive side sourced from the
connected transmission equipment. There was something special that was
done to "echo" at the local printout any typed keys, It seems that it
was jumpers at the transmission equipment between the incoming "xmit"
current and the outgoing "Rcvd" current, again it must have put them in
series. It also rings in my head that the interfaces changed when 20ma
came out and they could not be intermixed. A machine would be either 60ma
or 20ma and required an overhaul to change it. 20ma was a result of reduced
physical part requirements for robustness and EMF splatter reduction.
Test equipment of the time put out "RY's", and that was almost a perfect
square wave at 120Vdc, 60ma as I remember. I have conveniently forgotten
most of what we did to repair these units, but I do remember a tank where
the units were given a bath in something??? If air couldn't get things
cleared and freed up, it got a bath then a complete relube???!!!!
The comments to "running open were correct. That is the sign that no
current was available to the unit. The current kept it "held".
On Thursday, October 9, 2003, at 04:52 PM, Tom Jennings wrote:
>> I have been attempting to get my ASR33 teletype connected to something
>> and communicating, but so far I have not been successful. I have built
>> the interface here :
>> http://www.daedalus.co.nz/~don/computing/20mahack.html
>
>
> It wont work, sorry...
>
Somehow I'm not surprised. Something told me that it was too simple to
work properly.
> Teletypes are inductive loads. Though they only want 20 mils, the
> voltage needs to be high to get the initial magnet pull-in (basic RL
> theory). ASR33 loops were generally run at 100V or so, but I run my
> Model 28 at 14V, with non-perfect error rate, and I don't use the
> keyboard.
I take it that the voltage isn't that crucial, just the current?
> The keyboard and printer are IN SERIES. If you hit keys while it's
> printing you foul it up. Normal.
What about on a full duplex machine? Is it the same, or are they
separate?
> Because it's inductive, it makes a spike when yuo turn the voltage off.
> You need to suppress this with a diode, a resistor and capacitor, for
> example.
>
> They're not subtle interfaces, and weren't meant to be.
>
> If you just want to print, you can rig up a power transistor, two
> resistors, a diode, and a high-voltage DC power supply to do the trick,
> and drive it from the serial port.
>
> If you want to receieve also, you can use another transistor and
> resistor to pick off the change in loop current that happens when you
> press keys which open the loop, and drive the serial port.
>
> I've done one of these fairly recently, and if poked with a
> not-too-sharp stick, I'll scan the schematic and pu on my website.
*poke*
<grin>
If it's not too much trouble, I'd like to see it. From what I have
heard, there are lots of ways to do this, and i would be very
interested to see how you did it.
Thanks!
Ian Primus
ian_primus(a)yahoo.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.528 / Virus Database: 324 - Release Date: 10/16/2003
Does anyone have a copy of the host system software for the circa 1984
Seiko RC-1000 watch terminal?
I thought I had a copy that ran on DOS as a character mode app, but I
cannot find the original diskette. The original PC I used is long gone.
Dave.
>From: "ben franchuk" <bfranchuk(a)jetnet.ab.ca>
>
>Tony Duell wrote:
>>>>C requires a stack pointer and a index register.Offhand I don't think
>>>>your hardware supports that.
>>>
>>>Certain HP2xxx do have index registers (the ones with the EIG instructions
>>>IIRC), but guess how FORTRAN compilers handle indexed array accesses
>>
>>
>> Err, self-modifying code? That was the traditional way to do this sort of
>> thing.
>
>I think the PC is noted more more self-modifying code than the old
>machines. The only real self modifying code (on your typical early
>machine) is the fact the return address is placed in the first word
>of subroutine code.
>
>> -tony
>>
Hi
I don't call this self modifying. Where you have a port
command like the 8080 and you overwrite the port address
before executing, now that is self modifying. Something
like over writing an add instruction with a subtract
would qualify as self modifying. Placing the address at
the beginning is no different than pushing
the address onto a stack, other than that it isn't reentrant
( with out extra code and then not for interrupts ). The
first address isn't code, it is a variable space. The executed
code never changes.
My Nicolet uses the entry address saving method.
In any case, I never understood the stigma of using self
modifying code. It does require careful documentation if
it is expected to be maintained. There is no reason why
it can't be as robust as any other code if done properly.
I suspect it was used as a sales talk when someone was
trying to pitch their version of code to be better than
someone else's. Such things as overlays would qualify as
more risky uses of self modifying code but that is done
without mention.
Dwight
On Oct 16, 13:40, John Lawson wrote:
> ----------------cut n paste----------------------------
>
> Received: from huey.classiccmp.org (huey.classiccmp.org
> [209.145.140.36])
> by mail3.panix.com (Postfix) with ESMTP
> id B220098214; Thu, 16 Oct 2003 13:00:45 -0400 (EDT)
> Received: from huey.classiccmp.org (localhost [127.0.0.1])
> by huey.classiccmp.org (8.12.8p1/8.12.8) with ESMTP id
> h9GGjaH5086939;
> Thu, 16 Oct 2003 11:45:38 -0500 (CDT)
> (envelope-from cctalk-bounces(a)classiccmp.org)
> Received: from linux.local ([128.195.166.138])
> by huey.classiccmp.org (8.12.8p1/8.12.8) with ESMTP id
> h9DIMuH3076162
> for <cctalk(a)classiccmp.org>;
> Mon, 13 Oct 2003 13:22:56 -0500 (CDT)
> (envelope-from tomj(a)wps.com)
> Received: by linux.local (Postfix, from userid 500)
> id A6B2C378DC; Mon, 13 Oct 2003 11:14:43 -0700 (PDT)
> From: Tom Jennings <tomj(a)wps.com>
> To: cctalk(a)classiccmp.org
> In-Reply-To: <200310131508.h9DF8gH5075481(a)huey.classiccmp.org>
>
>
> ------------end cut n paste-----------------
>
> I see there is quite a delay between two of the entries - 3 days.
As
> Arte Johnson used to say on Laugh-In: "Veeeeeeeery Eeeenteresting!"
But schtupid :-)
Those headers show that it took a few minutes to get tpo
huey.classiccmp.org (acting as receiver) -- that might be just mismatch
between the clocks -- and then 3 days to get to be forwarded (from the
same machine!). I've noticed a few headers with delays since we last
discussed this, but none quite as extreme! However, I can think of
some possible reasons.
In this case, I'd guess that for some reason (maybe the sender isn't
subscribed, or sent from an address that differs in some way from the
address he subscribed with) the message had to be moderated -- we rely
on Jay's goodwill and free time to do that, and if he's busy, I imagine
that he does the really obvious ones in batches where he doesn't really
need to examine them closely, and some get held over for a closer look
when time permits. He also has to sleep and eat sometimes!
In some other cases I've noticed, where the delay is a few hours, the
same reasoning might still apply, even to messages sent by a
subscriber. If you send to the list, and your headers give a different
username, hostname, or domainname than the one you used to subscribe,
it will need to be moderated.
Another possibility is that any kind of DNS lookup failure -- including
a slow response -- could cause the sending process on huey to requeue
the message. This happens a lot with people who use dynamic DNS
services and try to run their own mailserver on an ADSL line. They
forget that even though they can update the DNS within a few seconds
(or usually several minutes) when their IP address changes, most of the
rest of the world that's interested in them has already cached the old
data and it doesn't expire for a while (I've know it take days).
Yet another possibility right now, with all the viruses, and floods of
mail saying "we didn't deliver your mail because it had a virus and
we're too stupid to read the headers and see they're forged"[1] (not
mentioning AOL or certain other ISPs) is that some ISPs are finding
their mail servers swamped and hence slow. The ISPs that have suddenly
put virus-checking in place are particularly badly off, because the
scanning takes several times as many computrons as simple mail handling
does. huey might try to deliver a message and not be able to at some
particular instant, so it gets requeued. I've seen this happening on
our mailservers at work (we can easily handle what we're getting and
sending, but sometimes outgoing mail is queued because the recipient's
servers can't).
The above also happens a lot with ADSL users trying to run their own
servers, because right now some of them are getting hit with lots of
spam and virus-generated crap. However, that wouldn't explain why you
saw such a delay (since panix is not a little linux box on the end of a
DSL line).
[1] Several viruses currently forge the "From" line, making it seem
that email from some infected machine actually came from a different
user/machine. Easy to spot if you bother to look, but lots of people
-- even serious ISPs -- don't.
There are lots of other possibilites. Most mail transport agents, like
sendmail, have several built-in timeout functions, to cover various
eventualities. Sendmail has loads of them, mostly short, but the net
effect is that if some check or lookup takes too long, the associated
email is queued. Most MTAs only run the queues periodically (common
settings in sendmail are every 15 or 30 minutes) so you see that if
some recipient has some systematic problem (like bad/slow DNS, or being
hammered by DOS attacks or viruses) it doesn't take many delivery
attempts for the delay to mount up *for that recipient*. One I came
across the other day was that one sendmail was trying to do an ident
lookup on incoming mail. The ident protocol is an old and not very
useful way of trying to validate a sender's username; not many people
run ident daemons so if a recipient's server tries to do this
validation, it can take tens of seconds for it to decide it's not going
to get anywhere with it. Meanwhile, the sender may give up. Another
one I've seen, though not for a little while, is using an out-of-date
blackhole list -- depending on how the recipient server checks
blackhole lists, it might take a long time to decide whether to accept
a message, and meanwhile -- you guessed it -- the sender has given up
waiting and requeued the mail.
--
Pete Peter Turnbull
Network Manager
University of York
Ok, the folks at www.auctionbdi.com have put these out in their current
auction (which ends Sunday, October 19th at midnight pacific time. The lot
numbers are as follows:
SJ-97 for the 3400s, MV2, and 4000/300. Plus a pair of skis?
SJ-98 for the VAX in the H9644 cabinet with the SCSI drives (the door says
MicroVAX 3600 I believe).
SJ-99 is the pallet of mixed stuff I believe. (The pictures aren't up yet...)
--Chuck
--------------------- Previous Email ...
A number of VAXen are available this week from www.auctionbdi.com. I gave
them all of my "spares machines" which I cannot store and no one in the Bay
Area wanted. The good news is that BDI will ship them to you pretty much
anywhere in the country and the minimum bid is $25. The lot to look for has
3 MV3400's (in BA213 cases), one VAX 4000/300 (in a BA440 case) and one
MicroVAX II in a pedestal BA23 case. I don't recall how complete they are,
I do thing the 4000/300 is complete except for some DSSI plugs which I
needed to bring my 3800 on line. Two of the 3400's have the front "door"
(one says MicroVAX 3400, one says VAXServer 3400). If you've got a 3400 or
4000/300 there are plenty of parts to "enhance" your system. I believe the
4000/300 has 192MB of memory but can't swear to it)
There is also a MicroVAX 3600 in a H9644 rack. This one I've never looked
at in depth other than to note that it has a 4 SCSI drives and a tape but a
gap where the SCSI controller had been. Given that it couldn't talk to the
disks I pretty much ignored it.
Finally there are some PC parts with a nice 17" NEC 5fg monitor (including
the special NEC VGA cable). The monitor is nice but not an "Energy Saver"
(it stays on as long as power is applied, no standby mode) Probably not of
interest to this crowd but I thought I would mention it.
--Chuck
