Piotr,
I had problems with my KA694 system at first, I reseated all the
cards including
the power supply and problems went away.
Dan
On Wed 02/29/12 8:42 AM , VCOMP vcomp99 at gmail.com sent:
Dan,
On 02/26/2012 05:46 PM, Daniel Snyder wrote:
> Piotr,
>
> Found the KA694 maintenance manual. Looks as though powerup tests
must
> finish
> to the console prompt in order to perform a firmware upgrade. What
> number do
> the tests freeze at?
>
> Below is a normal powerup sequence:
>
> KA694-A V2.4, VMB 2.15
> Performing normal system tests.
> 70..69..68..67..66..65..64..63..62..61..60..59..58..57..56..55..
> 54..53..52..51..50..49..48..47..46..45..44..43..42..41..40..39..
> 38..37..36..35..34..33..32..31..30..29..28..27..26..25..24..23..
> 22..21..20..19..18..17..16..15..14..13..12..11..10..09..08..07..
> 06..05..04..03..
> Tests completed.
> Loading system software.
> (BOOT/R5:0 DIA0)
>
> I have looked on Google for the firmware file, did not find it.
> Maybe try the comp.sys.dec or comp.os.vms newgroups for
> answers. I even looked in some old Condists for the file.
> Someone who came from DEC field service may be able
> to provide a solution.
>
> Dan
Thank you for your help and hints - I'll try to ask at c.s.d. and
c.o.v.
As for the boot problems - during startup, system tests are stoping
in
different stage - sometimes I see first two lines, sometimes I see
nothing except 'Performing normal system test' and sometimes it
hangs
after all tests complete... It's very strange, and the firmware is
my
first suspect. Unfortunately, I don't have spare CPU card so I can't
verify what is the real problem...
Regards,
Piotr
Hi All
For some time now, I'm a happy owner of a VAX 4000-705 system.
Unfortunately, it came with corrupted firmware, and I don't have
replacement KA694... In 'KA694 CPU System Maintenance' I found
information that there were FEPROM updates distributed (AFAIK it was
called Firmware Update Utility). Can someone on this list point me to a
source for that? Or at least the firmware image alone?
TIA,
Piotr
I have been scanning and OCRing BYTE magazines, and so far have a stack two feet tall of magazines which have been de-spined with a large paper cutter.
Dates are from 1978 to 1987 - not all issues are present.
They are free to anyone who wants to pick-up or pay shipping.
They are in southern California, Orange County, 92656
I have half as many which have NOT been de-spined, and are intact - someone else has already scanned those issues, so I won't cut up mine, but will still give them away - nothing earlier than 1980 though.
Steve.
On Fri, 17 Feb 2012 22:17:17 +0000 (GMT), ard at p850ug1.demon.co.uk (Tony
Duell) wrote:
> A few comments...
>
> 1) I can find nothing to suggest that this has anythign to do with the
> UK. The televisoin company is not a UK one (AFAIK), and while is at least
> one small village in England called Melbourne, I cna't beleive it had
> much of a hacker./cracker community.
They are based in Sydney and Melbourne, Australia. They must mean
Melbourne, Australia.
/Jonas
Hi Johannes,
I can assure you there has never been a problem like this with KryoFlux.
Our devs work in software engineering for large companies (e.g. console
hardware and games, chances are you already own a device that has code
made by one of us) and are trained to the latest standards. Even dumps
made with the very first public beta are valid in regard to data
integrity and there is no need to redump anything. There are hundreds of
units out in the field, some at large institutes and libraries, where
they are being used daily. It's a device made by preservationists for
preservationists.
For the record: KryoFlux' counters are 32 bits wide. This is no hardware
limitation, it was just chosen as sufficient, but we could as well move
to 64 if needed.
I would recommend our forums at http://forum.kryoflux.com/ which should
give you an impression about user satisfaction. We recently added ADF
writing, with more formats to follow.
Best,
Chris
Am 27.02.2012 19:00, schrieb cctalk-request at classiccmp.org:
> Has anyone heard of problems with Kyroflux?
I remember taking a copy of NewDos 2.1+ , and an issue of 80-Micro to my local Radio Shack and using their Model I to apply zaps to the OS to speed up the boot and step speed. The store manager thought I was crazy, but it worked great! There were also zaps for TRS-DOS 1.3 which I applied to a copy of that, and made copies for the store.
They gave out the faster TRS-DOS to all their disk drive sales as a way to enhance the sale. By that time, the drives were all Tandon TM-100's and could easily handle 12ms stepping. I think I also applied the 40 track patch as well.
Al Hartman
From: Eric Smith <eric at brouhaha.com>
On 02/26/2012 01:56 PM, Fred Cisin wrote:
> One of the things that I remember about Apparat (slightly before that)?
> was that NewDOS (was it only in NewDos80, or all the way back to?
> APRDOS?) gave the user the capability to set the step time, to be able?
> to take advantage of the 5ms step time of the Tandon, etc. drives,?
> rather than have to always step everything at 40ms to be able to?
> handle the original SA400 (the original drive shipped with TRS80).?
IIRC, NEWDOS/80 allowed the step rate to be changed on a per-drive basis?
using the PDRIVE command. In fact, you could change an amazing number of?
parameters for the drive or the filesystem format using that command.
I don't think NEWDOS had such a command, though there might have been?
ZAPs (patches) to change the step rate globally.|
Hello,
Does anyone have access to a Murata databook from the 1998 - 2004 time
frame? I'm looking for a datasheet for a particular part and have not
been able to find anything online.
Please contact me off-list. Thanks!
Cheers,
Dan
dan at decodesystems.com
I don't know what was the slowest, but I suspect u can get by with what was
the slowest defacto industry standard as default and not worry about anyone
who was faster.
As I recall Shugart dominated the 8 and 5? inch FDs and they were not
buffered. So your step rates from their specs are
SA800 ? 8 msec
SA400 ? 40 msec
SA400L ? 20 msec
I believe most of the 3? did use buffered seek and I would get the Sony
spec, not the first Sony but the one that complied with the MIC standard
cartridge spec. Sony may have adopted the Shugart spec, which was:
SA300 Unbuffered ? 6 msec
SA300 Buffered ? 50 usec minimum period; 1 usec minimum pulse width
The SA1000 8-inch HDD from a secondary source apparently can accept buffered
pulses at a 1.0 u sec min spacing.
The ST506 OEM manual is at Bitsavers; it was unbuffered only at 3 msec
minimum period, 10 usec minimum pulse width. (there was a hidden internal
second pulse generated at 2.8 msec)
The ST412 specification [Apr 82] was one Seagate buffered mode
implementation that most everyone had to follow
ST412 Unbuffered ? 3 msec
ST412 Buffered ? 25 usec minimum period; 200 usec maximum period, 2.0 usec
minimum pulse width
Microprocessor utilization on the ST412 adds the capability of capturing and
storing up to 305 step pulses. The controller may burst pulses to the 412
and they will be accepted until 1) time after last pulse exceeds 200 usec or
2) 305 step pulses are received. At the occurrence of either of these
conditions, the ST 412 microprocessor will stop accepting step pulses from
the controller and will begin issuing them to the stepper motor. Depending
on the length of seek, the microprocessor will select the optimum algorithm.
Any pulses issued at a rate between 200 usec and 3 msec may be lost.
Note the subsequent ST212 (Apr 84) has a buffered spec of 5 usec min, 500
usec max with a 2 usec min pulse width.
So I would set my defaults
Unbuffered FDD seek ? 40 msec
Buffered FDD seek ? not supported
Unbuffered HDD seek ? 6 msec
Buffered HDD Seek ? 25 usec period with a 2 usec pulse
Good luck
Tom
> From: classiccmp at philpem.me.uk
>
> Hi guys,
>
> Does anyone know what the typical range of floppy and ST506/ST412 drive
> track-to-track seek rates is?
>
> I'm finding myself having to modify the seek logic in the DiscFerret to
> accommodate the Seagate ST-277R RLL drive, which requires that
> buffered-seek pulses be spaced between 8 and 200 microseconds apart. Any
> more than that and it assumes you're doing a 'slow' seek at 10ms per
> step.
>
> At the moment the DiscFerret's step rates are set up in 250us intervals,
> with an 8-bit divider register. Seek rates can be between 250
> microseconds and 64 milliseconds in this configuration.
>
> Feeding the ST277R the 250us step pulses... really screws it up. The
> drive deasserts READY and SEEK-COMPLETE and seems to freeze up
> completely. Hardly unexpected...
>
> If I change the seek clock to 125us, I get a minimum of 125us and a
> maximum of 32ms using the same divider.
>
> Is 32ms likely to be enough for even the slowest drives?
>
> Out of curiosity, does anyone know what the slowest-seeking floppy drive
> or MFM/RLL hard drive ever made was, and what its track-to-track seek
> rate was?
>
> Thanks,
> --
> Phil.
> classiccmp at philpem.me.uk
> http://www.philpem.me.uk/
Hi guys,
Does anyone know what the typical range of floppy and ST506/ST412 drive
track-to-track seek rates is?
I'm finding myself having to modify the seek logic in the DiscFerret to
accommodate the Seagate ST-277R RLL drive, which requires that
buffered-seek pulses be spaced between 8 and 200 microseconds apart. Any
more than that and it assumes you're doing a 'slow' seek at 10ms per step.
At the moment the DiscFerret's step rates are set up in 250us intervals,
with an 8-bit divider register. Seek rates can be between 250
microseconds and 64 milliseconds in this configuration.
Feeding the ST277R the 250us step pulses... really screws it up. The
drive deasserts READY and SEEK-COMPLETE and seems to freeze up
completely. Hardly unexpected...
If I change the seek clock to 125us, I get a minimum of 125us and a
maximum of 32ms using the same divider.
Is 32ms likely to be enough for even the slowest drives?
Out of curiosity, does anyone know what the slowest-seeking floppy drive
or MFM/RLL hard drive ever made was, and what its track-to-track seek
rate was?
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
>
> > > > It used to be the case that TVs synced to the mains
> > > frequency but I don't
> > >
> > > Was it?
> >
> > A long time ago...
>
> OK, I am sceptical. What do you mean by a 'long time ago'?
>
> Unti lthe coming of the National Grid, different areas would be supplied
> with mains at slightly differnet frequencies (even assuming it was
> supposed to be nominally 50Hz), and therre would eb no phase relationship
> at all. So usign that for any form of TV synchronisation is a non-starter.
>
> So that really limits us to post-WW2 TVs. The oldest book of schematics I
> have is dated 1953, but it contains models going back to 1948. Not one
> attempts to derrive the vertical sync signal from the mains as far as I
> can see.
>
>
I'm not sure why I'm getting into this, seeing as I know little about it.
However...
Perhaps studio sync sources were derived from mains power at one time purely
as a method of picking a reference to use so that there would be minimal
picture roll when transmission output is switched between different sources?
Maybe this was found to be counterproductive when large changes in load caused
momentarty variations in frequency even though the electricity producers worked
to average these out in the longer term?
(I don't have any guesses as to what might have been used for a line sync
source.)
If a three phase grid system is in use with individual receivers normally
connected to single phase supplies derived from it and having no choice as to
which phase they ended up getting powered by, it would seem to be rather
more difficult to attempt to use the power supply waveform as a sync source for
reception than to use the sync pulses present in the transmission.
Regards,
Peter Coghlan.