If you are planning to participate in the VCF 4.0 Exhibit then now is the
time to register! The cut-off date for exhibit registration is September
20th.
http://www.vintage.org/2000/exhibit.html
Keep in mind that aside from the fabulous cash and prizes you can win,
you will have a group of adoring groupies worhsipping your nerdliness!
Register today!!
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
I have a fair # of the docs for these. I won't have the time to dig them
out until late next week however. If you will remind me off list toward the
end of next week and forward your add I will dig them out and drop them in
UPS to you. All I ask is please make copies and return them sometime within
a month or so.
Dan
>
>The remaining boards are from VG Data Systems. Someone here once mentioned
>they had information about some of these boards, and i'd like to know
>if any of these boards might be useful, or easily modified to be
>useful:
>
>PB-8E-101
>PB-8E-102
>PB-8E-202 on a standard DEC wirewrap board, should be able to make
> something out of it.
>PB-8E-504 2 of this board
>PB-8E-505
>PB-8A-603
>PB-8E-644 input connector has written: works as MS30, PDP8 [C:]
>
>-Lawrence LeMay
From: Eric Smith <eric(a)brouhaha.com>
>> Suffice to say IDE is not a protocal like SCSI it is a DEVICE
>> interface and is somewhat uncooked at that.
>
>That's a fairly disingenuous claim. Both SCSI and IDE have a "device
>interface" (physical layer) and a "protocol" (interpretation of bytes
>in various registers and phases).
In one sense your right and in another your making it look complex
where it's not.
For scsi I have to deal with the SCSI interface chip (really nasty if
it's
5380!). For IDE I write/read to registers at addresses, al having
specific function. there is some sense of sequence and if you want
it to work you need to talk to the right one in the right order or
garbage
ensues. I liken it more to talking to an Z80 SIO raw than making the
SIO do HDLC and at the end of that link getting something
to happen. IDE is much simpler. I've done SCSI it's not!
>IDE in fact has two different protocols, ATA and ATAPI; ATAPI protocol
>is by design very similar to SCSI protocol.
Already known.
>As of SCSI 3, there are *many* different SCSI physical layers and
>several different protocols.
The difference between IDE and SCSI(any) is that from the CPU side if
I want to write the cylinder address to IDE I address the correct
register
and write (assuming not LBA). For SCSI I first have to talk to the scsi
chip and tell it what to say to the disk. The later already is a full
layer
of protocal from what you want to do.
The point originally being that IDE is the simplest disk interface there
is of the available sets and from doing a driver for z80 I can say its
easier than floppy as the interface if buffered, not time critical reads
or writes as the data flys by.
Allison
Please note: I sent the following post to "alt.sys.pdp11" and
"vmsnet.pdp-11". While I presume that almost all of the RT-11
people also follow those two news groups, I thought that there
may be a few who don't. It is certainly on topic, since V5.03
of RT-11 was released in 1985.
After working with RT-11 for over 20 years starting with V2.0,
I was asked about Y2K patches for V5.04G by a customer who
finally could wait no longer. I had already produced these Y2K
patches for myself, but there seemed to be little if any interest among
commercial users in general. So when I set out to provide this
customer with the fixes needed to run that version when it was to be
used after 31-Dec-1999, it was not necessary to fix everything in
V5.04G. Only 7 of the utility programs were needed to be made
Y2K compatible, i.e. DIR, PIP, LINK, LIBR, IND, BUP and
MACRO. While I am sure that further work could be considered
if required (and there was interest), these 7 are probably the most
important and frequently used - along with the source code patches
needed for the monitor files. Note that these patches have been
in continual commercial use for many years without any problems
except that when they did their initial checkout, the dates of:
29-Feb-1999, 30-Feb-1999 and 31-Feb-1999 were found to
be acceptable to the DATE command. After working with RT-11
for so many years, I had finally accepted that bug as a feature and
forgotten to correct it in the KMOVLY.MAC file.
At this point, all of my Y2K work bubble is finished and complete,
and I would like to make these Y2K patches available to hobby
users. However, as far as I understand, only V5.03 of RT-11
qualifies to be used under the Supnik emulator for hobby use
free of charge. Since Megan Gentry has already provided some
source code patches for RMONSJ, RMONFB and KMOVLY
for V5.03 of RT-11, I thought that I could retro-fit the Y2K patches
made for V5.04G back into V5.03 so that hobby users could enjoy
a mostly Y2K version of RT-11 at this time.
I would therefore ask for four things:
1. If anyone, including Megan Gentry, would be willing to host
the Y2K patches, preferably the actual final SAV file which should
not pose a problem since the distribution SAV file for each of the
7 utilities mentioned is already freely available for download under
the restriction that it be used by hobby users under the Supnik emulator.
2. How much interest there actually is in having V5.03 made as Y2K
compatible as possible at this time.
3. If there is anyone who would be interested in helping with a beta test.
4. If there is anyone who is interested in helping with any questions as
the exactly what should be done, including how to insure that the legal
aspects are covered and that the code can not be taken over by any
commercial users, not that this latter aspect is likely at this time.
At this point, I intend to at the very least, to produce the Y2K patches
for one of the above utilities so that it can be seen that there is some
definite interest to begin the job.
Please note that while I have no work related projects that need to be
done at this point, I have a large number of household jobs that have
already been delayed for far too long and that it may take a few months
before I get into high gear on the Y2K patches for V5.03 project.
But, as wives have indicated on many occasions, there is often many
a slip between the cup and the lip and she may have other plans that I
am not aware of right now. However, I presently consider myself
totally in the hobby category at this point in time, especially and in
particular as far as RT-11 is concerned.
This would allow Mentec to finalize any plans for hobby releases of
PDP-11 software, as has been indicated on their web site for over two
months, but still nothing has been made public.
But in lieu of that happening - which would free up useful time for
other enhancements to RT-11, it is hopeful that at least the above
7 utilities in V5.03 of RT-11 could be completed for hobby users
sometime next year and perhaps before the end of 2000 if there is
sufficient interest - and I don't have too much snow to shovel starting
in December:-)
NOTE: The following paragraph is really only for "vmsnet.pdp-11"!!!!!!
----------------------------------------------------------------------------------
Finally, and completely contrary to what Stuart Brook implied some
months ago when he again complained that I was "whining" about
the lack of hobby use licenses for RT-11 by Mentec/Compaq/DEC,
I would be only too happy to see Mentec allow V5.07 to be made
available to hobby users at this time, as Compaq/DEC have already
done with current versions of VMS - and I understand at zero cost.
I have included this paragraph ONLY because in the past, there has
been this type of response from Stuart. If no adverse comments are
received from Stuart or anyone else, then I will assume that there are
no objections from Mentec as to the above course of action. I guess
that this paragraph can also be construed as a legal notice as to an
intended course of action.
Any and all feedback would be appreciated. Is there still anyone who
even cares? Also, in case anyone is interested, you can download
V5.03 at:
ftp://gatekeeper.dec.com/pub/digital/sim/software/rtv53swre.tar.Z
Sincerely yours,
Jerome Fine
Hi,
Does somebody here know the formulas for calculating the offsets and bits
in the CGA memory? Or maybe a quick routine for plotting a pixel? The BIOS
routine sure seems SLOW to me. I'm experimenting with these older
machines, so I'm working a little with these cool graphics cards! (The CGA
is great! Well, I LOVE IT! :-) )
Ciao,
Lionel
From: Jerome Fine <jhfine(a)idirect.com>
>> The later boards could possibly even be enough to fake the IDE
interface
>> directly. Even an old clunky 120mb WD2120 would seem large!
>
>Jerome Fine replies:
>
>Any ideas as to how the DRV11-J (M8049) might need to be programmed
>to interface to an IDE drive? Any could that become a device driver?
Some but it's too involved to talk about without drawing pictures.
Suffice to say IDE is not a protocal like SCSI it is a DEVICE
interface and is somewhat uncooked at that. It happens the devices
on the other side are fairly intelligent and thats an aid to the driver.
First off the driver would have to be written.
>I have heard that there is a possibility of using an IDE as the disk
drive
>behind a controller that would be able to use the HD(X).SYS device
>driver that John Wilson makes use of in the E11 emulation software.
??? I dont work with emulators so none of that is of any meaning to me.
>In addition, it has been suggested that even a SCSI drive might be OK
>as well. What might be involved in producing such an animal? While
SCSI is non trivial to do and also the driver can be a pain.
>HD(X).SYS is far too simple a concept to use in an OS that requires
>multi-tasking, like RSX, for RT-11 it seems like the perfect solution.
>Unfortunately, I have so little hardware knowledge that I do not know
>even what questions should be asked.
Actually a simple driver can work if it's reentrant. However, while
RT-11
is fairly simple to write drivers for the other OSs it definately more
work
as the driver has error recovery and other diagnostice code burried in
it.
Unix hwoever is a different case as a driver for something like RL02
might be easily bent to work with IDE.
Allison
Well, now that my PDP-8/E is apparently working, but has no peripherals
installed yet, my curiousity over what these 'mystery omnibus boards'
do is increasing. If anyone can shed some light, i'm all ears:
----
Computer Operations Inc, C-10450-01. This board intrigues me the most,
as someone has written this on the board with a marker:
[LINK DEC TAPE 2]
It has connectors for 3 ribbon cables to attach, 26 wires per cable.
Connectors are labeled: CDJ2, CCJ1, CDJ1.
----
The remaining boards are from VG Data Systems. Someone here once mentioned
they had information about some of these boards, and i'd like to know
if any of these boards might be useful, or easily modified to be
useful:
PB-8E-101
PB-8E-102
PB-8E-202 on a standard DEC wirewrap board, should be able to make
something out of it.
PB-8E-504 2 of this board
PB-8E-505
PB-8A-603
PB-8E-644 input connector has written: works as MS30, PDP8 [C:]
-Lawrence LeMay
Not strictly on topic, since these are fairly new - but they were old enough to
be thrown out at work, and I got them for L10 each.
Both machines say Alphastation 200 4/100 on the front, and I think Model
PB40H-CA on the back.
One of them boots openVMS, for which I have no passwords (same old story...).
This machine claims her name is Tracey.
The other gets to the console prompt (>>>), and I haven't tried booting further.
(This machine is in a graphics mode my monitor doesn't like. Time to get a
better monitor...)
Anyway, if I press ctrl-C when booting Tracey, I can get to the console prompt.
SHOW CONFIG then tells me a bit about what's installed in her:
SRM Console X3.9-1387
ARC Console 4.1-22
PALcode VMS X5.48-87 OSF X1.35-57
Serial ROM V4.6
Diag ROM V1.6
CPU DECchip 21064-2 at 100MHz
pka0.7.0.6.0 SCSI 7
dka0.0.0.6.0 RZ26L (this is whence it boots, BTW)
dka100.1.0.6.0 RZ28
mka400.4.0.6.0 TLZ07 (This is a tape drive on the SCSI bus. Presumably at
address 4 - forgot to look when I had it in bits)
With some random flag adjustments to the BOOT command, I got it into SYSBOOT,
which has another load of useless things to SHOW and SET. This seems to be part
of VMS, though.
Can anyone tell me, off list if necessary:
How do I break into OpenVMS from here?
If I put in the floppy and CDROM drives from the other machine, will it
recognise them automatically on boot, and if not, how do I tell it they're
there?
What OS are available, and whence do I obtain them? I found a FAQ somewhere at
compaq.com about installing Linux on some models of Alphaserver - not mine, but
could be helpful. Also, what are the various OS useful for?
What are the HDDs? (How big, how easy to replace? They are both SCSI afaik)
If I decide to stay with VMS, are there any good books on the subject? I have
almost no VMS experience (enough to know that I have to PURGE my files from time
to time to stop my disk filling up, but that's about it!)
Philip.
**********************************************************************
This message and any attachments are confidential and should only be
read by those to whom they are addressed. If you are not the intended
recipient, please contact us, delete the message from your computer
and destroy any copies. Any distribution or copying without our prior
permission is prohibited.
Internet communications are not always secure and therefore the
PowerGen Group does not accept legal responsibility for this message.
The recipient is responsible for verifying its authenticity before
acting on the contents. Any views or opinions presented are solely
those of the author and do not necessarily represent those of the
PowerGen Group.
Power Technology:
Telephone +44 (0) 115 936 2000
Fax +44 (0) 115 936 2711
E-mail techinfo(a)powertech.co.uk
www http://www.powertech.co.uk
PowerGen UK plc Registered Office: 53 New Broad Street London EC2M 1SL
Registered in England and Wales No: 2366970
**********************************************************************
From: Richard Erlacher <richard(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Wednesday, July 05, 2000 7:30 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
>You may be onto something, Tim, but I'd make one observation here. The
>signal on pin2 of the 8" drive cable, though often driven with the
>1793's TG43 signal, does not turn write precomp on and off, but, rather,
>reduces the write current to the heads. This reduces the amplitude of
the
>signal
In many cases it's also used to alter write precomp. Most all have some
precomp (Esp DD controllers) and for the TG43 case they alter the precomp
to further compensate for bit shift due to the close magnetic domains.
>driving the heads, hence reduces the overall amplitude of the recovered
>signal as well. That same signal is used to enable write
precompensation on
Bogus. the levels are dealt with in the read amps with margin as well.
What's changing of the write current really impacts is the read bit shift
(aka peak shift) as the bit density goes up (inner tracks are shorter
than
outer).
>some controllers, many of which use a less-than-ideal timebase to define
>the precompensation offsets imposed on the data stream.
This is true, or worse used oneshots. generally the time base for the
bit encoding was always a crystal with not worse than 200ppm error
and less than 50ppm drift. The typical system was usually within
50ppm of exact and drifted less than 25ppm over temperature extremes.
Often the actual data rate was far lower than that reference(usually 1/4
or 1/8th).
>Do you think you could take a stab at swapping the timebase on your
>Catweasel board with a 32 MHz crystal? I think that would be VERY
>illuminating, particularly where these precomp/write-current-related
>effects
>are concerned, because phase noise introduced by the deviation of the
>Catweasel timebase from a harmonic of the data rate adds confusion.
There lies a connundrum, study the media and the magnetic domains therein
or get the data? A lower clock would be adaquate for getting the data.
Further, while I was studying digital PLL state machines I found a point
where increasing the clock (greater resolution) produced sharply reduced
improvement. Signal processing theory (analog) suggests the same.
From: Tim Mann <mann(a)pa.dec.com>:
>> So, what's the heuristic? It's quite crude and oversimplified too,
>> seems to work pretty well. The general idea is that if an interval is
>> a bit off from what you were expecting it to be, multiply the error by
>> some factor around 0.5 to 0.8 (you sometimes have to tune it for each
>> disk if they are particularly bad), and add that to the next interval
I'd suggest some factor less than .5, flux shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose. Actually based on media and expected recording rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
It is serediptious that the code you have effectively accomplishes
a tracking filter (type of PLL). Why, many of the parameters on
the media like peakshift and other behavours tend to average
themselves and cancle. Most of this stuff is not rocket science,
it does however require seeing into the set of abstractions to
make them obvious.
Allison
