test-drb August 2000

test-drb@ccmp.vtda.org

152 participants
352 discussions

Start a nNew thread

test - please ignore

by west＠tseinc.com

testing something on the mail archives. Please ignore. Jay West

23 years, 10 months

Exhibit at VCF 4.0!

by vcf＠siconic.com

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!

23 years, 10 months

Omnibus boards

by dburrows＠netpath.net

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

23 years, 10 months

M8207 anyone?

by ajp166＠bellatlantic.net

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

23 years, 10 months

Y2K Patches for V5.03 of RT-11

by jhfine＠idirect.com

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

23 years, 10 months

CGA graphics

by lionelp＠worldonline.co.za

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

23 years, 10 months

M8207 anyone?

by ajp166＠bellatlantic.net

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

23 years, 10 months

Omnibus boards

by lemay＠cs.umn.edu

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

23 years, 10 months

Alphastation help

by Philip.Belben＠powertech.co.uk

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 **********************************************************************

23 years, 10 months

Tim's own version of the Catweasel/Compaticard/whatever

by allisonp＠world.std.com

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

23 years, 10 months

← Newer
1
...
21
22
23
24
25
26
27
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb August 2000