>From: "Huw Davies" <huw.davies at kerberos.davies.net.au>
---snip---
>
>Are the risks in preemptive scheduling just ones of complexity? I guess
>that it is much harder to "prove" that this type of scheduler is going
>to to the right thing at the right time. I know that,
>for example, the scheduler for VMS has gone from a couple of pages of
>assembler
>to something like 75 pages of BLISS!
>>
Hi Huw
I think it is more about predictability. Large preemptive
systems can lock up in unpredictable ways. They are hard
to confirm as operating correctly under all conditions
since the number of permutations of conditions is so large.
This makes them dangerous for critical systems.
Most non-preemptive system are easier to find bugs because
they tend to fail right away if there is such a flaw.
Also, preemptive taskers often have to save greater amounts
of information since they may break a task at in opportune
points.
For a general purpose OS, preemptive makes sense. For
RTOS is really doesn't.
As an example of simplicity, for an embedded machine, I used
a non-preemptive tasker to run 50 pid controls, a keypad,
paper printer log and a LCD display. This was all easily handled
with a single 2MHz Z80.
Dwight
>From: "vrs" <vrs at msn.com>
---snip---
>
>What you are saying is consistent with what I see on most sites selling
>these things. There, "run" caps are generally oil, and "start" caps are
>generally electrolytic. The exception being the occasional "start/run" cap,
>whatever that is.
I believe that refers to how it is used. During the start,
it is connected to a high current coil but during run, is
is connected to a high resistant one to create phase shift.
>
>The original caps in the TU56 are high capacitance, and clearly
>electrolytic. But they appear to be wired for continuous phase shifting
>duty. Hence some of the people on the list insisting that they are "run"
>caps, and that the beefier, more expensive "run" cap should be used.
Most likely to make the motor run smoother, as though there
were more phases to the AC.
---snip---
Dwight
Does anyone have a discription of how drives are mounted in a 7012/7030 RS/6k
with the 2 front accessible 5-1/4 bays? (not the case with the card-edge
connector for narrow SCSI) I think I need some type of sled or cage, but I don't
know how it attaches or the IBM lingo for it (so Google doesn't work).
- Scott Quinn
>From: "Giuseppe Sarno" <gsarno at nortel.com>
>
>Hi I own an Old Xerox 820 machine,
>Can anyone help to find documentation for it ?
>Also is there a way to download programs onto it using the serial/parallel
>port ?
>
>I have seen some info at
>http://www.classiccmp.org/pipermail/cctech/2002-September/002642.html
><http://www.classiccmp.org/pipermail/cctech/2002-September/002642.html> but
>I couldn't find more.
>
>Thanks.
>
Hi
You didn't mention if you have a disk that boots and
has PIP under CP/M on it. If you do, you can transfer
information as ASCII like a BASIC source program or even
transfer .COM files by first converting them to .HEX
files and then using DDT on the 820 to move them
to .COM files.
If you are attempting to bootstrap with no disk, you'll
have to check with others. One may be able to do it
if it has a built in debug monitor.
Of course, on can always write some of ones own code
and replace one of the internal EPROMs. It is not
as impossible as it sounds. You just have to explore
a little.
Dwight
>From: "Eric Smith" <eric at brouhaha.com>
>
>Paul wrote:
>> all too often, priorities
>> are used to hide the fact that the builder didn't analyze the job
>> sufficiently, and simply hacked the priorities until things seemed to
>> work in test.
>
>True. You wouldn't believe how many times I've seen other engineers
>trying to set the priority of their task higher than those of other
>tasks just because they have some vague idea that their task is
>"important", rather than any understanding of actual relationships between
>the tasks.
>
>A good rule of thumb is that in the absence of a rational basis for
>one task having a higher priority than another, all tasks should have
>the same priority. Far too often a person's intuitive idea of what
>the relative task priorities should be is wrong.
>
>Eric
>
>
Hi
If it is important enough to need immediate attention,
it should be interrupt driven and not a general task.
Many confuse interrupts with tasks. I suspect this is
mostly because most preemptive systems use the interrupts
to switch task( not very efficient in a RTOS ).
Even in a non-preemptive, one can have some priority.
Management of the task queue can give similar effects.
Dwight
Hi everyone,
Well, I am finally getting around to trying to recover some 26
9-track tapes I have been holding on to for
at least 10 years. Some are closer to 25 years. I found out six of
them had no data, and a bunch more I
have been able to read and decode, including some RT-11 tapes and some
VAX SIG tapes. Sorry this
monologue won't make much sense to you non-DEC folks, but you might have
ideas on converting from 800
to 1600 BPI anyway.
Here is my dilemna. I have 6 tapes that look like they are 800 BPI, and
were most likely written on an RSX-11
system. I have no 800 BPI setup, and if I did, it would be on a VAX,
which may not be able to restore the
savesets anyway. That is because I have a few more tapes that I can
read (or at least dump) but I cannot unpack
the savesets. It would appear that the tapes were written in the early
days of VMS when the backup and restore
utilities were really RSX-11 BCK/RST derivitives, and the current BACKUP
program does not recognize
the container file as a valid saveset.
The label on the front of several tapes date them early 80's and talks
about BCK format. The dump sort of looks
like BCK stuff. The blocksize is 2064.
I've had a couple of offers to try to recover the data, but I was
checking to see if anybody was set up to easily
read and recover the data, without a lot of reconfiguration or hassle.
I'm open to suggestions. I suspect if I knew
the layout of a BCK container/saveset I could unpack them myself (except
for the 800 BPI stuff). Any ideas??
I also have an XXDP tape, labeled MSDP, which makes me think it is
bootable. It would be nice to duplicate
it, as it is not easily read to disk. The first block is 14 bytes, and
the rest look like 512 bytes.
And finally, I have a tape that is readable, is mountable under VMS and
I can copy nearly everything off of.
That is, the 400+ files up to the file that is marked HECK.BCK. That
file is 2064 byte blocks, which makes
me think it is also a BCK/RST format. Can't figure how I got it on the
end of the tape and haven't figured
out how to get it back.
Cheers,
Joe Heck
It's not-quite-on-topic but it's a well-developed evolutionary
dead-end; a platypus display. It *could* be done on old gear...
>From Tim Pozar:
Vector drawings on an o'scope using a sound card on a computer....
http://www.sensi.org/~svo/pr0nscope/
On Mon, 14 Mar 2005 Bj?rn <bv at norbionics.com> wrote:
> On Sun, 13 Mar 2005 20:36:58 +0100, Eric Smith <eric at brouhaha.com> wrote:
>
>> Ethan writes about bytes on the PDP-10:
>>> On the -10,
>>> one stores 6 6-bit characters in a machine word, and one speaks of
>>> bytes that are 6 bits.
>>
>> Not necessarily. On the PDP-10, the byte size could be anywhere from
>> zero (really!) to 36 bits. Seven bits was the most commonly used for
>> general ASCII text, with one leftover bit per word. In fact, this
>> was so common that the KS10 CPU has special dedicated hardware to make
>> the 7-bit byte case more efficient than the other supported byte sizes.
> ...
>
> A byte is the smallest INDIVIDUALLY addressable unit of data on a system.
Nonsense! Where did you get that?
The PDP-10 is an excellent example of when this isn't true.
The smallest addressable unit is a word, which is 36 bits.
A byte is, as noted, anything between 0 and 36 bits. Bytes are stored in a
word, as many as can be fitted.
To access bytes on a PDP-10, you have a byte pointer, which consist of a
word address, and a bit pointer, and byte size. So it points to the
correct word, and then you have a bitfield in that word that a nice
instruction can extract, and also move the bitfield pointer ahead the
correct amount and move on the the next word, if the next byte would not
fit in this word.
A byte is simply a convenient number of bits enough to store a character.
No explicit definition of how many "convenient" is, nor what character set
we're talking about with "character". A byte is just that. A convenient
size typ for character data.
The fact that people today seem to believe that byte addressable is the
only possible thing, along with a byte being 8 bits, is plain and simply
because they haven't seen any other.
> It was usual to speak of a character when a part of a whole word was
> extracted. I do not remember any details of the Univac 1107 (I only
> programmed in FORTRAN and Simula on it), but I think the normal character
> was six bits. I am fairly certain that was not a byte, it was extracted
> from an 18-bit halfword or a 36-bit word. A byte is something you can load
> and store to an individual address, and the hardware takes care of the
> rest. A character needs some software or firmware mapping in order to read
> or write just one of them.
Bah. A sixbit character can very well be a byte, it's just a question of
if you choose to call it that.
Byte addressable is not usable as a definition of a byte.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> It's not-quite-on-topic but it's a well-developed
> evolutionary dead-end; a platypus display. It *could* be done
> on old gear...
>
> >From Tim Pozar:
>
> Vector drawings on an o'scope using a sound card on a computer....
>
> http://www.sensi.org/~svo/pr0nscope/
WAY too much time on their hands :-)