Re: RT-11 V4 MU-BASIC help

2018-03-29 Thread Mattis Lind via cctalk
fredag 30 mars 2018 skrev Fritz Mueller via cctalk :

>
> > On Mar 29, 2018, at 9:53 PM, Mattis Lind  wrote:
> >
> > I have imaged some RX01 and RX02 floppy disks with RT11 V3B and MU
> Basic.  http://www.datormuseum.se/documentation-software/rx01-
> and-rx02-floppy-disks  documentation-software/rx01-and-rx02-floppy-disks>
>
> Hi Mattis,
>
> I did find your page above while googling, but the links seem dead
> (returns a 404 page from dropbox?)


Oops! Sorry. Dropbox removed deeplinking to dropbox files and I started to
move files to new storage solution. But many files are still on the todo
list. I fix those files asap..

I'll get back soon.

/Mattis


>
> thanks much,
>--FritzM.
>
>
>
>


Re: RT-11 V4 MU-BASIC help

2018-03-29 Thread Fritz Mueller via cctalk

> On Mar 29, 2018, at 9:53 PM, Mattis Lind  wrote:
> 
> I have imaged some RX01 and RX02 floppy disks with RT11 V3B and MU Basic.  
> http://www.datormuseum.se/documentation-software/rx01-and-rx02-floppy-disks 
> 

Hi Mattis,

I did find your page above while googling, but the links seem dead (returns a 
404 page from dropbox?)

thanks much,
   --FritzM.





Re: RT-11 V4 MU-BASIC help

2018-03-29 Thread Mattis Lind via cctalk
fredag 30 mars 2018 skrev Fritz Mueller via cctalk :

> Hello all,
>
> I would like to try and get MU-BASIC working on my PDP-11/45, under RT-11
> V4.  The best bits I've been able to find to work with so far are the RK05
> image here:
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp11/
> discimages/rk05/rt11v4-mubasicv2.rk.gz
>
> ...but I've not had much success getting this to work under simh.  Using
> the 1USER.CNF configuration file in this image, no matter how I configure
> the machine, I get either traps, halts, or stack violations when issuing
> the first command in basic.
>
> Trying to rebuild MU-BASIC using the indirect files in the image results
> in a linker barf on some undefined symbols.
>
> Has anybody else here had much luck getting MU-BASIC up and running under
> RT-11 V4?  Is there an alternate image or distribution kit somewhere that I
> could try to work with?


I have imaged some RX01 and RX02 floppy disks with RT11 V3B and MU Basic.
http://www.datormuseum.se/documentation-software/rx01-and-rx02-floppy-disks

Not tested getting them running though.

/Mattis


> thanks much,
>   --FritzM.
>
>
>


Re: Speed now & then (Space and time?)

2018-03-29 Thread Zane Healy via cctalk

> On Mar 29, 2018, at 7:00 PM, Jon Elson via cctalk  
> wrote:
> 
> Then, in 1986, I bought a MicroVAX-II CPU board from a broker, and a bunch of 
> 3rd party peripherals, and made a copy of VMS 4.7 (Might have used something 
> earlier for a time.)
> I was in 7th heaven!  A REAL computer at LAST!

And now a Raspberry Pi running SIMH can emulate a faster VAX system than that 
MicroVAX II.  I’m slowly getting my VMS cluster back up and running, but 
through emulation.  My goal is to power down my Alpha, except when I need a 
couple programs that won’t run on a VAX.  My fastest VAX (beating my VAXstation 
4000/60) is SIMH running on an ESXI server.

Zane




Re: Speed now & then (Space and time?)

2018-03-29 Thread Mark Linimon via cctalk
On Thu, Mar 29, 2018 at 04:05:10PM -0700, Chuck Guzis via cctalk wrote:
> And yet, productive work was performed on it.  Indeed the industrial
> variant, the 1710 was used for early process control.

There were a lot of highway improvements made in the US in the 1950s/
1960s using Bendix G-15s.  That particular branch of civil engineering
was probably that machine's biggest customer.  (OTOH, disclaimer: the
one I used in high school had previously been owned by an oil company.)

mcl


Re: Speed now & then (Space and time?)

2018-03-29 Thread Mark Linimon via cctalk
On Thu, Mar 29, 2018 at 09:00:35PM -0500, Jon Elson via cctalk wrote:
> It was an absolute DOG!  It took several minutes for Emacs to load.

So, uh, I hate to tell you about the state of the art these days ...

mcl


Re: Speed now & then (Space and time?)

2018-03-29 Thread Jon Elson via cctalk

On 03/29/2018 04:24 PM, Fred Cisin via cctalk wrote:


I posited that 2 decades ago in a wired article.  My CP/M 
machine booted

in seconds while waiting for
the winders box to decide if it would/could.


"The new machine is so much faster, that it can almost get 
out of its own way!"



From 1978 or so, I had a Z-80 CP/M system running on the 
S-100 bus. In about 1980, I got a Memorex Winchester drive 
on it.  It really made CP/M fly.


In 1982-1984 or so, I was trying to build a 32-bit machine 
very loosely patterned after an IBM 360, but would have used 
a 360 user-level instruction set.  It became obvious that it 
would take years to have an OS, compilers, utilities, etc.  
(I did not know about Unix 360, which I almost certainly 
could have gotten a copy of, we had a PDP-11 Unix license at 
the university.)


So, I cloned a Logical Microcomputer Co. Genix system with 
the Nat. Semi 16032 chip.  It was an absolute DOG!  It took 
several minutes for Emacs to load.  Even vi (which I 
detest!) was horribly slow, like 10X slower than the CP/M 
editor.


Then, in 1986, I bought a MicroVAX-II CPU board from a 
broker, and a bunch of 3rd party peripherals, and made a 
copy of VMS 4.7 (Might have used something earlier for a time.)

I was in 7th heaven!  A REAL computer at LAST!

Jon


RT-11 V4 MU-BASIC help

2018-03-29 Thread Fritz Mueller via cctalk
Hello all,

I would like to try and get MU-BASIC working on my PDP-11/45, under RT-11 V4.  
The best bits I've been able to find to work with so far are the RK05 image 
here:


http://bitsavers.trailing-edge.com/bits/DEC/pdp11/discimages/rk05/rt11v4-mubasicv2.rk.gz

...but I've not had much success getting this to work under simh.  Using the 
1USER.CNF configuration file in this image, no matter how I configure the 
machine, I get either traps, halts, or stack violations when issuing the first 
command in basic.

Trying to rebuild MU-BASIC using the indirect files in the image results in a 
linker barf on some undefined symbols.

Has anybody else here had much luck getting MU-BASIC up and running under RT-11 
V4?  Is there an alternate image or distribution kit somewhere that I could try 
to work with?

thanks much,
  --FritzM.




Re: Looking for opinions...

2018-03-29 Thread Paul Koning via cctalk


>>> ...
>>  " Three considerations suggest that he [Bush] was unaware of the detail
>>  of Goldberg's work when he [Bush] built his prototype in 1938-40: [. . 
>> .] "
>> and makes no conclusion of conscious influence (on Bush by Goldberg).
>> So when you say Bush "stole", and "claimed it as his own", etc., do you have 
>> some other reference or is this merely your pejorative accusation and 
>> hyperbole?
>>> Bush did not successfully build his machine.
>> (Not the Memex you mention, but, as discussed in the article, he did build 
>> the predecessor 'microfilm rapid selector'.)
> 
> Yes, my statement was overy harsh.

Maybe relevant here, maybe not, but it's worth keeping in mind that history is 
full of things that were "discovered" several times.  The name that is 
remembered tends to be the name associated with the instance that took hold, 
not necessarily the first one.  Examples include America, frequency modulation, 
telegraphy, and many others.

paul




Re: Speed now & then (Space and time?)

2018-03-29 Thread Paul Koning via cctalk


> On Mar 29, 2018, at 7:05 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 03/29/2018 02:24 PM, Fred Cisin via cctalk wrote:
 HOWEVER, a variant of "Boyle's Law" warns that software and content
 will expand to fit all available space and speed.
>> 
>> On Thu, 29 Mar 2018, allison via cctalk wrote:
>>> We have proof and it is us.
>> 
>> Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is us."
>> 
>>> I posited that 2 decades ago in a wired article.  My CP/M machine booted
>>> in seconds while waiting for
>>> the winders box to decide if it would/could.
>> 
>> "The new machine is so much faster, that it can almost get out of its
>> own way!"
> 
> As a real contrast, consider, say, the IBM 1620.  Go look up the cycle
> times on that beast.
> 
> And yet, productive work was performed on it.  Indeed the industrial
> variant, the 1710 was used for early process control.

Or drum machines.  Dutch airplane maker Fokker used one (FERTA) for airplane 
design.  And its successor ARMAC was where the Internet routing algorithm 
(shortest path algorithm) was first run.

paul




Re: Looking for opinions...

2018-03-29 Thread Fred Cisin via cctalk

If only that were 16mm or 35mm continuous rolls, instead of microfiche!
In 1931, Emanuel Goldberg, then a chief engineer at Zeiss built the "Statistical 
Machine". By recording bits optically in the margins of microfilm, and reading them 
with photocells, it could find appropriate frames!
For use in soundtrack for films, Mauer puts up to 8 parallel variable area 
optical tracks in the margin!
8 bit parallel!
Goldberg was also apparently responsible for the Contax camera.
BUT, in the days leading up to World War Two, he fled Dresden and Zeiss could 
not afford to have mention of a Jew in a high profile position, and by the time 
the war ended, they had systematically erased most clues that he had existed!
http://people.ischool.berkeley.edu/~buckland/goldberg.html
A decade later, Vannevar Bush stole the idea, and without credit, claimed it as 
his own, as the foundation for his Memex device.

 [...]

On Thu, 29 Mar 2018, Brent Hilpert via cctalk wrote:

An article ( http://people.ischool.berkeley.edu/~buckland/goldbush.html ) on 
your referenced site assesses the state of the art in between Goldberg and Bush 
(1931-1938).
Near the end the writer states:
" Three considerations suggest that he [Bush] was unaware of the detail
of Goldberg's work when he [Bush] built his prototype in 1938-40: [. . .] 
"
and makes no conclusion of conscious influence (on Bush by Goldberg).
So when you say Bush "stole", and "claimed it as his own", etc., do you have 
some other reference or is this merely your pejorative accusation and hyperbole?

Bush did not successfully build his machine.

(Not the Memex you mention, but, as discussed in the article, he did build the 
predecessor 'microfilm rapid selector'.)


Yes, my statement was overy harsh.
Yes, I knew Buckland's research well.  He was my PhD advisor.

No, there is no smoking gun.
(cf. no Gary Kildall easter egg in MS-DOS)
During the early stages, over 20 years ago, ran into a few references to 
others in the field who felt slighted over not being credited by Bush, 
including one who had met personally with Bush, and who made mention 
in passing of having discussed the prior work (inc. Goldberg) with Bush.



Bush's Atlantic Monthly article, "As We May Think" is sometimes considered the 
foundation of modern information science.
Bush did not understand nor accept the concepts of index nor hierarchical 
organization, so he pushed for linkage to go from one topic into another.
Ted Nelson credits it as the inspiration for Hypertext, and Cern credits Ted 
nelson.


Bush did do some important stuff.  Nobody else accomplished as much 
towards raising consciousness of the whole idea of Information Science.


Ted Nelson, when he coined the term "Hypertext", explicitly credits Bush 
with the concept.
He is far from the only person who prefer to think in terms of chained 
links rather than hierarchical structures for information.
There's a decent example of casual "surfing" in "Hyperland" (BBC; Douglas 
Adams, Ted Nelson, and Tom Baker in 1990 talking about the future of the 
internet.  I have made an SRT file for it.)




Re: RAID? Was: PATA hard disks, anyone?

2018-03-29 Thread Chuck Guzis via cctalk
On 03/29/2018 03:48 PM, Alexander Schreiber via cctalk wrote:

> Also, AFS is built around volumes (think "virtual disks") and you have
> the concept of a r/w volume with (potentially) a pile of r/o volumes
> snapshotted from it. So one thing I did was that every (r/w) volume
> had a directory .backup in its root where there was mounted a r/o
> volume snapshooted from the r/w volume around midnight every day.

CDC 6000 SCOPE 3.3 and later implemented permanent files with file
"cycles".   That is, earlier versions of a file were kept around.

The approach was a little different.  You initially started a job or
session with no files, but for INPUT (wherever it came from) OUTPUT
(display or print output) and optionally PUNCH (obvious meaning).  A
dayfile was also maintained, but the individual user could only add to
it, not otherwise manipulate it.

To do real work on an ongoing project involved ATTACH-ing a permanent
file that had been CATALOG-ed.  Paswords (up to 3) and permissions
needed to be specified to ATTACH a file.  This, IIRC, created a local
copy of the file.   If you mistakenly deleted the local copy, you still
had the permanent copy.  If you saved the local copy after modifying it,
it was saved as a new cycle.

A user could PURGE old permanent file cycles.

The beauty of this was that a user had access to the files that were
needed for a session.  A user could, of course, create as many local
files as desired, but these were all disposed of at the end of the
job/session, so there wasn't a lot of garbage floating around in the system.

A side benefit was that permanent files could be archived to tape, so
when an ATTACH was issued for an archived file, the job was suspended
until the relevant tape was located and read.

I suspect that modern users would consider the system to be too
restrictive for today's tastes, but it was fine back then.

--Chuck



Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Peter Coghlan via cctalk
>
> > J8 (position 0) is where the jumper already is on both my 3000 600 machines.
> > It is possible that this is where it normally is, however, it is also 
> > possible
> > that I moved it there some time ago in an attempt to diagnose the problem 
> > and
> > I have since forgotten.  Which position is the jumper at in your system?
>
> It's in at position 0 (J8), as per documentation.
>

It looks like position 0 (J8) is the normal operating position for the jumper
then and I did not move mine previously.  With the jumper in this position,
I get some mini console output on power up but I do not get an SROM> prompt
and I cannot enter mini console commands unless a machine check happens or I
force an error by removing a memory riser or doing something else to cause
an error.

If I put the jumper in position 3 (J6), I get this:

DEC 3000 - M600 SROM 6.1
Mini-Console
ff.fd.fb.fa.f9.f8.f7.f6.f5.f4.f3.f2.f1.f0.
sysROM  0033.06f1
ioROM   0033.0162
MCRstat .808011c0
bnkSize 0300.0c01
memSize 00c0.00c0


SROM>

which seems on first glance like what I am looking for.  However, commands are
not accepted or echoed which is strange!

Even more strange, if I put the jumper in position 2 (J7), I get exactly the
same output and the same lack of response to commands but at 19200 bps while
pretty much every other setting talks at 9600 bps (except for position 7 (J1)
which doesn't seem to do anything).

The remaining settings perform some cache tests and produce lots of failures.
It looks I can only enter mini console commands with the jumper in position 0
(J8) after some error has happened.

(I do not get anything on the MMJ console port under any cirumstances.)
   
>
>  These must be the alternative diagnostic routines mentioned the system 
> programmer's manual:
>
> "A DECchip 21064-AA CPU, including on-chip 8-KB instruction and 8-KB data 
> caches, and a 64-KB serial boot ROM.  A 64-KB stream holds the primitive 
> boot code for booting the operating system.  Jumpers provide for the 
> selection of up to seven other streams for diagnostic and other purposes. 
> (The entire UVPROM is 64 K x 8.)"
>

Yes.  I didn't bother trying these jumpers earlier as not having description
of the the diagnostics, I thought their operation might be rather obscure.
Happily some of them at least are pretty simple and obvious.

>
> I take it F0 is the last output from SROM before handing control over to 
> SRM.  Now that you've got a way to see SROM diagnostic output directly I 
> would expect these codes not to matter as much anymore.
>

It appears I was confused.  In chapter 14 of flspcsva, table 14-1 "Power-Up
Test Serial ROM Codes" seemingly applies to the DEC 3000 800 only, despite
being in the part III "Common System Information" section of the manual.

Regards,
Peter Coghlan.

>
> Maciej
>


Re: Speed now & then (Space and time?)

2018-03-29 Thread Chuck Guzis via cctalk
On 03/29/2018 02:24 PM, Fred Cisin via cctalk wrote:
>>> HOWEVER, a variant of "Boyle's Law" warns that software and content
>>> will expand to fit all available space and speed.
> 
> On Thu, 29 Mar 2018, allison via cctalk wrote:
>> We have proof and it is us.
> 
> Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is us."
> 
>> I posited that 2 decades ago in a wired article.  My CP/M machine booted
>> in seconds while waiting for
>> the winders box to decide if it would/could.
> 
> "The new machine is so much faster, that it can almost get out of its
> own way!"

As a real contrast, consider, say, the IBM 1620.  Go look up the cycle
times on that beast.

And yet, productive work was performed on it.  Indeed the industrial
variant, the 1710 was used for early process control.

Now that I don't need to work on the bleeding edge, I prefer to see how
much can be done with the least.

It's fun.

--Chuck



Re: RAID? Was: PATA hard disks, anyone?

2018-03-29 Thread Alexander Schreiber via cctalk
On Wed, Mar 28, 2018 at 01:17:08PM -0400, Ethan via cctalk wrote:
> > I know of no RAID setup that can save me >from stupid.
> 
> I use rsync. I manually rsync the working disks to the backup disks every
> week or two. Working disks have the shares to other hosts. If something
> happens to that data, deleted by accident or encrypted by malware. Meh.
> 
> Hardware like netapp and maybe filesystems in open source have those awesome
> snapshot systems with there is directory tree that has past time version of
> data. A directory of 15 minutes ago, one of 6 hours ago, etc is what we had
> setup at a prior gig.

At a prior job, I replaced the standard NFS+Samba filesharing mess (with
the regular "I need you to twiddle permissions" fun) with an AFS server.
Native clients for both Linux and Windows2000. With access to the ACLs
built right into the native interfaces, so that regular call went away.

Also, AFS is built around volumes (think "virtual disks") and you have
the concept of a r/w volume with (potentially) a pile of r/o volumes
snapshotted from it. So one thing I did was that every (r/w) volume
had a directory .backup in its root where there was mounted a r/o
volume snapshooted from the r/w volume around midnight every day.

That killed about 95% of the "I accidently deleted $FILE, can you please
dig it out of the backup" calls.

Plus, it made backups darn easy.

Last I heard, after I left that place, they setup a second AFS server.

Oh, AFS as in: the Andrew File System

Kind regards,
   Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."  -- Thomas A. Edison


Re: RAID? Was: PATA hard disks, anyone?

2018-03-29 Thread Alexander Schreiber via cctalk
On Tue, Mar 27, 2018 at 10:26:53PM -0300, Paul Berger via cctalk wrote:
> 
> 
> On 2018-03-27 10:05 PM, Ali via cctalk wrote:
> > 
> > 
> >  Original message 
> > From: Fred Cisin via cctalk 
> > Date: 3/27/18  5:51 PM  (GMT-08:00)
> > To: "General Discussion: On-Topic and Off-Topic Posts" 
> > 
> > Subject: RAID? Was: PATA hard disks, anyone?
> > 
> > How many drives would you need, to be able to set up a RAID, or hot
> > swappable RAUD (Redundant Array of Unreliable Drives), that could give
> > decent reliability with such drives?
> > 10 -
> > Two sets of 5 drive  RAID 6 volumes in a RAID 1 array.
> > You would then need to lose 5 drives before data failure is imminent. The 
> > 6th one will do you in. If you haven't fixed 50 percent failure then you 
> > deserve to lose your data.
> > Disclaimer: this is my totally unscientific unprofessional and biased 
> > estimate. My daily activities of life have nothing to do with the IT 
> > industry. Proceed at your own peril. Etc. Etc.
> > -Ali
> > 
> > 
> To meet Fred's original criteria you would only need 4 to create a minimal
> RAID 6 array.  In theory a RAID 1 array (mirrored) of 4 or more disk could
> also survive a second disk failure as long as one copy of all the pairs in
> the array survive but you are starting to play the odds, and I know of some
> cases where people have lost . You can improve the odds by having a hot
> spare that automatically take over for a failed disk.  One of  the most
> important things is the array manager has to have some way of notifying you
> that there has been a failure so that you can take action, however my
> observations as a hardware support person is that even when there is error
> notification it is often missed or ignored until subsequent failures kill
> off the array.   It also appears to be a fairly common notion that if you
> have RAID there is no need to ever backup, but I assure you RAID is not
> foolproof and arrays do fail.

Repeat 10 times after me: "RAID is NOT backup".

If you only have online backup, you don't have backup, you have easy
to erase/corrupt copies.

If you don't have offline offsite backup, you don't have backup, you have
copies that will die when your facility/house/datacenter burns down/gets
flooded/broken into and looted.

And yes, in a previous job I did data recovery from a machine that
sat in a flooded store. Was nicely light-brown (from the muck in the water)
until about 2cm below the tape drive, so the last backup tape survived.
It missed about 24h of store sales data - which _did_ exist as paper
copies, but typing those in by hand ... yuck.

So we shipped the machine to the head office, removed the covers,
put it into a room together with some space heaters and fans blowing
directly on it and left if for two weeks to dry out.

Then fired it up and managed to scrape all the database data off it
while hearing and seeing (in the system logs) the disks dying.

Why didn't they have offsite backups? Well, that was about 12 years ago
and at that time, having sufficiently fat datalinks between every store
(lots of them) and the head office was deemed just way too [obscenity]
expensive. We did have datalinks to all of them, so at least we got
realtime monitoring.

There are good reasons why part of my private backup strategy is
tapes sitting in a bank vault.

I'm also currently dumping a it-would-massively-suck-to-lose-this dataset
to mdisc BD media. There I'm reasonably confident about the long term
survival of the media, what worries me is the long term availability of
the _drives_. Ah well, if you care about the data, you'll eternally have
to forward-copy anyway.

>   One of the big problems facing using large
> disks to build arrays is the number of accesses just to build the array may
> put a serious dent in the speced number of accesses before error or in some
> cases even exceed it.

That is actually becoming a problem, yes. Moreso, for rebuild - with
RAID5, you might encounter a second disk failure during rebuild, at
which point you are ... in a bad place. Forget about RAID5, go straight
to RAID6.

Kind regards,
Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."  -- Thomas A. Edison


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Glen Slick via cctalk
In other vintage microfiche scanning news:

The Vintage Tek Museum (www.vintagetek.org) has in its possession a
treasure trove of over 3 Million pages of microfiche...

https://www.youcaring.com/vintagetekmuseum-1085244

https://www.youtube.com/watch?v=AToH0P9D2IE


Re: Speed now & then (Space and time?)

2018-03-29 Thread Fred Cisin via cctalk

HOWEVER, a variant of "Boyle's Law" warns that software and content
will expand to fit all available space and speed.


On Thu, 29 Mar 2018, allison via cctalk wrote:

We have proof and it is us.


Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is us."


I posited that 2 decades ago in a wired article.  My CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.


"The new machine is so much faster, that it can almost get out of its own 
way!"




It is hideous.   But you need the picture. 


How should I react to the college administator who told me, "You're not 
seeing the big picture"?   :-)   I was considering defenestration.




HTML has helped that along.

HTML is not nearly so bad its slightly bigger than runoff only wordier.
However that we need HTML for a screen of text is, yes, bad!
I blame WYSISWYG, and Postscript!  WYGINS  (for those that forgot, What
You Get Is No Surprise)
from the days before high resolution printers.


Nothing wrong with a markup language.  It's the application to 
inappropriate uses.
WYSIWYG was touted as being professional approach.  But the typesetter who 
I used to use never needed, nor wanted, a PICTURE of how a line of text 
would look with the fonts he chose.
I did a lot of my early work in YAFIYGI (You Asked For It, You Got IT) 
systems, such as manually embedding Cordata or PCL font commands in my 
text.



One college administrator managed that with ease.  He created the memo
. . . 
But, that was almost a decade ago.  I wonder whether he is now

attaching MP4s?



Eep, the man is batty.


I feel guilty about not having defenestrated the college administration.



Dancing kangaroos and yodelling jellyfish has let form triumph over
content!   When will we finally have smell-o-vision?

Please no, smell-o-vision.  I can see the hackers going for the cross
between skunk, pepperspray,
and some toxic chemical mess.   Obviously a Blacktooth perpiheral.


It will need a Fart virus.



Yes, certainly, the hardware is much faster, and has more storage space.
Yet, the task takes longer, and storage space runs out just as quickly.

Thats the whole sad story.   It is why I still run CP/M, RT-11 and even
a DECMate!  All hail fanfold!
Allison


Allison is wonderful!
Somebody who understands what I've been ranting about!
"So, THIS is 'progress'?"

--
Grumpy Ol' Fred ci...@xenosoft.com


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Fred Cisin via cctalk

On Thu, 29 Mar 2018, geneb via cctalk wrote:
I'm probably WAY over simplifying this because I don't have a grasp of the 
optics involved, but wouldn't it be possible to get a good image of 
individual pages on a microfiche by using a DSLR with the right lens and a 
CNC X/Y table made from one of the large (8x10) LED illuminators used to 
treat SAD?  The lights are pretty bright and are under $50.


Getting EVEN illumination throughout the frame will still be an issue. BIG 
issue for photographic images, but still a minor issue for bitonal text 
and schematics.
Theoretical ideal is a point source with collimating "condenser" lenses 
(like the top half of an enlarger).  BUT, for this, a diffuse light 
source or an added diffuser MIGHT be adequate.  Particularly for bitonal, 
where half-tone density, or color balance, is not significant.




The X/Y table build would be very simple and cheap to build.


For you, maybe.  I'm a little overwhelmed contemplating that part of the 
project.  Even the film holder is a little work.
Which is why I was suggesting gutting a fiche reader for those mechanical 
parts, and then adding positioning mechanisms.



The only "real" expense would be the right lens on the camera.


That's the part thet I consider cheap and simple.
Start out with a camera with interchangeable lenses.  I'm partial to 
"Micro-Four-Thirds" and Sony Nex E-mount.  There's enough different ones 
that you can start cheap, and upgrade later, if you need to, without 
starting over.   Accesory items, such as extension tubes and lens mount 
adapters, are VERY available and cheap.


Start with the lens that comes with it.  You will need more extension for 
close focussing.  Crappy, but usually USABLE, extension tubes are 
available on eBay "cheaper than postage".  Bellows are not common for 
digital cameras, but used film camera bellows are readily available cheap, 
and adapters for mounting to the camera are cheap.  If you're not sure 
what to get, simplest are "Pentax M42" (42mm x 1.0) or "Leica Screw 
Mount" (39mm x 26tpi).  Exacta bellows are extremely cheap, but the 
adapter is a little harder to find.
It costs a LOT extra to get extension tubes that will keep the auto-focus, 
so don't plan on that.  Some cameras hava a semi-auto "focus assist", that 
will simply have the camera TELL you when it thinks that the image is in 
focus.  Calculate the extension

distance lens to subject = (extension+focallength)*focallength/extension
or make a guess and then move back and forth until you find how close your 
guess was.  Remember that an extension equal to the focal length will give 
you 1:1, with the back of the camera about 4 times the focal length from 
the subject.


Once you've tried that out with the lens that came with, . . .
Do a few frames manually to see how the quality is.
I want "FLAT-FIELD" lenses for this kind of stuff.  The cheapest are 
enlarger lenses.  Those are usually L39/M39/Leica screw mount (39mm x 
26tpi).  SOME are Schneider (25mm x 0.5mm), in which case you need to find 
the adapter between that and L39. 
You want a relatively SHORT lens!  The 100mm used in the recently 
discussed DIY scanner will require 4 inches of additional extension to get 
1:1, so you are looking at a LONG bellows combination.
35mm or 25mm would be easier, although better lenses are available in 
50mm. 
If you use a lens that was not for that kind of camera, you may need to 
experiment.  Leica camera lenses were intended for 28.8mm lens mount to 
film.  Enlarger lenses, inspite of same mount are not, and you will need 
to play with it to get a starting point for extension/focus.  Find a 
bright outdoor scene, which we will call "infinity".  Holding a sheet of 
paper, move it around to find the focus.  (NOT sun, or the paper may 
ignite).  THAT is your mount to image infinity distance, and will help you 
calculate how much you need to add on to the calculated extension.


If you really need to "cheap-out", and not go with even an interchangeable 
lens camera, . . .
There are cheap used attachments for slide duplication that fit on the 
front of a lens for 1:1.  If you zoom the lens in further, you may get 
enough to work.  Or at least let you capture 24x36mm in each exposure.


If you really want to undertand this stuff, find an OLD edition of The 
Leica Manual by Morgan & Lester.



The process could be automated by using a cheap SMD part vacuum (the little 
hand-held one I have ran about $10) attached to an arm that was run by some 
R/C servos.
You could use a webcam to image the whole sheet in order to obtain the title 
of the sheet and that image along with the individual page images could be 
stored together.  The webcam could also be used in conjunction with OpenCL to 
ensure that the fiche positioner got it right every time.


I would, of course, play with doing a few frames manually.
At least to get any idea of what SIZE the whole thing will need to be.
But, once that's working acceptably, a good 

Re: Speed now & then (Space and time?)

2018-03-29 Thread allison via cctalk
On 03/29/2018 03:35 PM, Fred Cisin via cctalk wrote:
> On Thu, 29 Mar 2018, Murray McCullough via cctalk wrote:
>> I’m not trying to date myself but have things truly sped up? In 1970’s
>> Toronto I had a classic computer, sorry can’t recall what it was,
>> connected
>> to a 300 baud modem; by early 80’s had ‘zoomed’ to 9600 baud. Oh, my!
>> [ A
>> typical file size to download was probably 1 MB. ] Speed indeed! Yet
>> now,
>> here in rural Ontario, Canada, I’m at 5MB/s. Yikes! (Friends in
>> Toronto are
>> at 50MB/s.) We can do the math but content, particularly multimedia, has
>> swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
>> that much slower? Happy computing. Murray  -:)
>
> Application of "Moore's Law" calls for a logarithmic increase in
> speed, such as doubling every 18 months.  Yes, the rate, in terms of
> bits per second has grown a lot.
> Similarly storage capacity has grown.
>
>
> HOWEVER, a variant of "Boyle's Law" warns that software and content
> will expand to fit all available space and speed.
>
We have proof and it is us.

>
> Once, if your handwriting is bad enough, you could type your grocery
> shopping list into Electric Pencil.  Took a few seconds.   later
> WordStar. Scripsit.  WordPervert.  Microsoft Weird. Does Clippy have a
> template for it?
> (PC-Write was a welcome respite in that growing bloat!)
>
I posited that 2 decades ago in a wired article.  My CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.


> It's kinda like: the plane flight is half an hour shorter, but the
> airport pre-processing in an hour longer.
>
I fly a Cessna150, cruse speed of 110mph, I could fly to Ohio in six
hours with one fuel stop.
Commercial flight is easily 4x faster and it still takes 6 hours door to
door. 

> Once, the operating system, such as PC-DOS 1.00, fit on a single sided
> MFM 160K floppy disk.  Now, much software comes on DVD, because CD-ROM
> (2/3 GB) isn't large enough!
>
Back when 160k was space, now it's a small entry in a table.

> A memo announcing change of room and time for a meeting is a very
> short paragraph.  That used to be about half a kilobyte.
> Now, it tends to be a few MB.
> It seems that some serious effort has to go into wasting so much
> capacity!
It is hideous.   But you need the picture. 

> HTML has helped that along.
>
HTML is not nearly so bad its slightly bigger than runoff only wordier.
However that we need HTML for a screen of text is, yes, bad!

I blame WYSISWYG, and Postscript!  WYGINS  (for those that forgot, What
You Get Is No Surprise)
from the days before high resolution printers.

> One college administrator managed that with ease.  He created the memo
> in his word processor, printed it on his color printer, signed it,
> SCANNED it, and attached the 24bit-color picture as an attachment to
> an email. The subject line of the email was: "FYI".  The text, other
> than the attachment was: "See attachment".  The attachment was an
> uncompressed picture of a line of text in the middle of a full sheet
> of paper:
> "The curriculum committee has been moved to room D-233 at 2:oo"
> But, in the memo, there was a horizontal rule that was not quite
> horizontal; one end was a few pixels higher than the other! - scanning
> with the paper not quite aligned may well be the easiest way to
> accomplish THAT!
> But, that was almost a decade ago.  I wonder whether he is now
> attaching MP4s?
>
Eep, the man is batty.

> MP4s mean that now, not only does it take MUCH longer to create the
> document, we can now waste MUCH more of the reader's time!
> I find it very annoying that when GOOGLE'ing to find a simple answer,
> many of the first hits are YouTube.
> A few seconds glance at a text document will likely tell me whether
> the answer to my question is there.  Or a sketch and maybe a
> photograph of somebody's hardware setup.  Instead, sit through minutes
> of talking heads.
> With background music to make it hard to make out what is being said!
> Youtube's "auto-generated CC" is a poor substitute for text.
>
>
> Dancing kangaroos and yodelling jellyfish has let form triumph over
> content!   When will we finally have smell-o-vision?
>
Please no, smell-o-vision.  I can see the hackers going for the cross
between skunk, pepperspray,
and some toxic chemical mess.   Obviously a Blacktooth perpiheral.

 I will nominally run without that peripheral.  Come to think of it I
did that for a decades regarding
sound.    Most of my favorite modern Linux machines can't squawk, peep,
hear, or see me.

> Yes, certainly, the hardware is much faster, and has more storage space.
> Yet, the task takes longer, and storage space runs out just as quickly.

Thats the whole sad story.   It is why I still run CP/M, RT-11 and even
a DECMate!  All hail fanfold!


Allison


Re: Speed now & then (Space and time?)

2018-03-29 Thread Fred Cisin via cctalk

On Thu, 29 Mar 2018, Murray McCullough via cctalk wrote:

I’m not trying to date myself but have things truly sped up? In 1970’s
Toronto I had a classic computer, sorry can’t recall what it was, connected
to a 300 baud modem; by early 80’s had ‘zoomed’ to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I’m at 5MB/s. Yikes! (Friends in Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray  -:)


Application of "Moore's Law" calls for a logarithmic increase in speed, 
such as doubling every 18 months.  Yes, the rate, in terms of bits per 
second has grown a lot.

Similarly storage capacity has grown.


HOWEVER, a variant of "Boyle's Law" warns that software and content will 
expand to fit all available space and speed.



Once, if your handwriting is bad enough, you could type your grocery 
shopping list into Electric Pencil.  Took a few seconds.   later WordStar. 
Scripsit.  WordPervert.  Microsoft Weird. 
Does Clippy have a template for it?

(PC-Write was a welcome respite in that growing bloat!)

It's kinda like: the plane flight is half an hour shorter, but the airport 
pre-processing in an hour longer.


Once, the operating system, such as PC-DOS 1.00, fit on a single sided MFM 
160K floppy disk.  Now, much software comes on DVD, because CD-ROM (2/3 
GB) isn't large enough!


A memo announcing change of room and time for a meeting is a very short 
paragraph.  That used to be about half a kilobyte.

Now, it tends to be a few MB.
It seems that some serious effort has to go into wasting so much capacity!
HTML has helped that along.

One college administrator managed that with ease.  He created the memo in 
his word processor, printed it on his color printer, signed it, SCANNED 
it, and attached the 24bit-color picture as an attachment to an email. 
The subject line of the email was: "FYI".  The text, other than the 
attachment was: "See attachment".  The attachment was an uncompressed 
picture of a line of text in the middle of a full sheet of paper:

"The curriculum committee has been moved to room D-233 at 2:oo"
But, in the memo, there was a horizontal rule that was not quite 
horizontal; one end was a few pixels higher than the other! - scanning 
with the paper not quite aligned may well be the easiest way to accomplish 
THAT!
But, that was almost a decade ago.  I wonder whether he is now attaching 
MP4s?


MP4s mean that now, not only does it take MUCH longer to create the 
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer, many 
of the first hits are YouTube.
A few seconds glance at a text document will likely tell me whether the 
answer to my question is there.  Or a sketch and maybe a photograph of 
somebody's hardware setup.  Instead, sit through minutes of talking heads.

With background music to make it hard to make out what is being said!
Youtube's "auto-generated CC" is a poor substitute for text.


Dancing kangaroos and yodelling jellyfish has let form triumph over 
content!   When will we finally have smell-o-vision?


Yes, certainly, the hardware is much faster, and has more storage space.
Yet, the task takes longer, and storage space runs out just as quickly.

--
Grumpy Ol' Fred ci...@xenosoft.com


Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Craig Ruff via cctalk
On the AXPpci33 board, the SROM is also an 8 bit device. What happens is that 
the CPU reads in a bit stream into cache at power up reset, where the specific 
bit stream is selected by the jumper position on the board. In effect the SROM 
can contain up to 8 bit streams. Some of them will make use of the SROM console 
port.

Re: Speed now & then

2018-03-29 Thread Ethan Dicks via cctalk
On Thu, Mar 29, 2018 at 12:20 PM, Murray McCullough via cctalk
 wrote:
> I’m not trying to date myself but have things truly sped up? In 1970’s
> ...  300 baud modem; by early 80’s had ‘zoomed’ to 9600 baud.

What hasn't changed is people.  Back when we had 300 baud, we only had
so many hours a night for eyeballs-on-slow text, so one could only
expect so much content to be transmitted.  File transfers were
hands-off, but even the graphic machines of the time had low-res
screens so a mono-graphic didn't take so long to pull down, unlike
640x480x8bit stuff that was common by the mid-90s.

As telecom speeds (modem then ISDN then DSL, etc, etc) ramped up, what
one could do in 60 seconds or even a 3-second attention span grew.
It's true that webpages have gotten really fat and the amount of media
one pulls down from a single click is staggering, but nobody would
have sat and waited that long for pages to load at dial-up speeds.
More bandwidth enables more to get pulled in the same amount of time,
it doesn't mean that anyone will stand still and load the same
quantity as before but faster.

It's like fixed purchase points for PCs or digital cameras or
whatever.  Each year, the new models cost about the same as the old
models but with more features.  The price points are set and as
technology gets cheaper, they just pack more in the box and leave the
price alone.  Same with telecom - more content, faster lines, same
time in chair.

-ethan


Re: Looking for opinions...

2018-03-29 Thread Brent Hilpert via cctalk
On 2018-Mar-28, at 6:52 PM, Fred Cisin via cctalk wrote:
  [...]
> If only that were 16mm or 35mm continuous rolls, instead of microfiche!
> 
> In 1931, Emanuel Goldberg, then a chief engineer at Zeiss built the 
> "Statistical Machine". By recording bits optically in the margins of 
> microfilm, and reading them with photocells, it could find appropriate frames!
> 
> For use in soundtrack for films, Mauer puts up to 8 parallel variable area 
> optical tracks in the margin!
> 8 bit parallel!
> Goldberg was also apparently responsible for the Contax camera.
> BUT, in the days leading up to World War Two, he fled Dresden and Zeiss could 
> not afford to have mention of a Jew in a high profile position, and by the 
> time the war ended, they had systematically erased most clues that he had 
> existed!
> 
> http://people.ischool.berkeley.edu/~buckland/goldberg.html
> 
> A decade later, Vannevar Bush stole the idea, and without credit, claimed it 
> as his own, as the foundation for his Memex device.


An article ( http://people.ischool.berkeley.edu/~buckland/goldbush.html ) on 
your referenced site assesses the state of the art in between Goldberg and Bush 
(1931-1938).
Near the end the writer states:

" Three considerations suggest that he [Bush] was unaware of the detail
of Goldberg's work when he [Bush] built his prototype in 1938-40: [. . 
.] "

and makes no conclusion of conscious influence (on Bush by Goldberg).

So when you say Bush "stole", and "claimed it as his own", etc., do you have 
some other reference or is this merely your pejorative accusation and hyperbole?


> Bush did not successfully build his machine.

(Not the Memex you mention, but, as discussed in the article, he did build the 
predecessor 'microfilm rapid selector'.)


> Bush's Atlantic Monthly article, "As We May Think" is sometimes considered 
> the foundation of modern information science.
> Bush did not understand nor accept the concepts of index nor hierarchical 
> organization, so he pushed for linkage to go from one topic into another.
> Ted Nelson credits it as the inspiration for Hypertext, and Cern credits Ted 
> nelson.



Re: Speed now & then

2018-03-29 Thread Paul Koning via cctalk


> On Mar 29, 2018, at 12:20 PM, Murray McCullough via cctalk 
>  wrote:
> 
> I’m not trying to date myself but have things truly sped up? In 1970’s
> Toronto I had a classic computer, sorry can’t recall what it was, connected
> to a 300 baud modem; by early 80’s had ‘zoomed’ to 9600 baud. Oh, my! [ A
> typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
> here in rural Ontario, Canada, I’m at 5MB/s. Yikes! (Friends in Toronto are
> at 50MB/s.) We can do the math but content, particularly multimedia, has
> swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
> that much slower? Happy computing. Murray  -:)

I remember downloading the GCC release kit over a 56k dialup line, in 2000.  
Took a while.

The ARPAnet in its early days had "high speed backbone" links which were 56k 
bps.  Terminal links presumably 110 bps, that being the speed of ASCII 
teletypes.  And back in the late 1970s you could still find even slower links 
in some places, such as 6 bit links connecting teletype machines for newspaper 
"wire service" feeds.

It would be fun to do a "generalized Moore's Law" chart, showing not just 
transistor count growth (Moore's subject) but also the many other scaling 
changes of computing: disk capacity, recording density, disk IOPS, disk 
bandwidth, ditto those for tape, CPU MIPS, memory size, memory bandwidth, 
network bandwidth...

All these have grown dramatically, but very clearly not in the same proportion, 
for some of these the changes are smooth while others are jumps, and the rate 
of change sometimes varies dramatically over the decades.

paul




Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Shaun Halstead via cctalk
On Thu, Mar 29, 2018 at 11:29 AM, Jon Elson via cctalk <
cctalk@classiccmp.org> wrote:
>
> Huh?  DEC service and software listings on Diazo?  Hmmm, you are right!  I
> always thought these were silver film, but just took a look and they are
> very dark blue Diazo.  On the other hand, these are VMS 4.2 fiche, so QUITE
> old, and look totally brand-new.  So, we have a few years yet to find a way
> to read them.
>

  Diazo duplicating film comes in a variety of dye colors.  Most of what we
used at my old shop was black, or the typical, recognizable blue.  Silver
duplicating film is far more resistant to fading, but is usually considered
to be too expensive for regular use, though some customers did specify
silver working copies.  Silver duplicating film is a little different from
silver original film, and it isn't always easy to tell whether a piece of
silver film is original or silver duplicate.
  As for diazo fade, there are several variables involved beginning before
the duplicates are ever created.  Age and storage conditions of the raw
film, light contamination (diazo is considered light-safe, but unprocessed
film will fade), heat and ammonia exposure prior to use and during
processing, storage conditions (heat, light, handling, humidity) after
processing.



> I am familiar with that frosty Diazo fiche that are very pale blue color,
> wouldn't be surprised if those faded.  They were never intended for
> archival storage.
>

  This is could be faded film, or it could have been a bad copy to start
with.  Insufficient ammonia during processing will cause a thin or pale
appearance.

  Another duplicate media I've encountered, though never in service
manuals, is vesicular.  It has a very distinctive appearance and texture,
and can be very difficult to scan, due to a low contrast.

--Shaun


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Ed Sharpe via cctalk
still have   5x7  durst  amazing enlarger 8 feet  tall  with vacuum register   
easel...  before  I  owned it... it was  used for  making color separations  
500w  agfa   condenser color head...  what a machine I  kept it just  
cuz  Ed#  www.smecc.org
 
 
In a message dated 3/29/2018 4:26:59 AM US Mountain Standard Time, 
cctalk@classiccmp.org writes:

 
LOL! I wish I still had my De Vere 5x4 enlarger, but I've nowhere to 
put such a thing. Anyway, although I have access to some 5x4 Sinar 
equipment, the largest format I still have of my own is a couple of 
Mamiya 645s.


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Jon Elson via cctalk

On 03/29/2018 09:54 AM, emanuel stiebler via cctalk wrote:

On 2018-03-28 22:26, Shaun Halstead via cctalk wrote:

All of the DEC film I
have (which I believe is already available) is diazo duplicates, which are
susceptible to fading over time, even when stored in proper conditions.

That's why we should do it now, not later ;-)

Huh?  DEC service and software listings on Diazo?  Hmmm, you 
are right!  I always thought these were silver film, but 
just took a look and they are very dark blue Diazo.  On the 
other hand, these are VMS 4.2 fiche, so QUITE old, and look 
totally brand-new.  So, we have a few years yet to find a 
way to read them.


I am familiar with that frosty Diazo fiche that are very 
pale blue color, wouldn't be surprised if those faded.  They 
were never intended for archival storage.


Jon


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Jon Elson via cctalk

On 03/29/2018 06:25 AM, Pete Turnbull via cctalk wrote:

On 29/03/2018 05:26, Shaun Halstead via cctalk wrote:

Using the wrong filament orientation can cause some weird 
artifacts
to appear on scanned images, because of the high 
magnification. I
strongly suspect that an attempt using an LED source 
would face

similar (and possibly worse) issues.


Light source.  Due to lensing requirements, LED's are 
probably out, unless a way can be found to suitably 
diffuse or blend the source without losing significant 
light.  This requires a very strong light source.


Yet there are plenty of LED light sources used in 
photomicroscopy so I
don't believe it's that hard to do,which is why I 
suggested it. I've seen it done with a high-brightness 5mm 
LED, but if a bit more "oomph" or a larger emitting area 
is required, there are inexpensive 1W and 3W LEDs that 
look like they'd work.  I'm no expert, but the biggest 
problem in photomicroscopy seems to be the spectrum, which 
isn't really an issue for monochrome microfiche.


I built a laser photoplotter (see 
http://pico-systems.com/photoplot.html ) to make PC board 
master artwork.
it does very accurate plotting at 1000 x 1000 DPI.  The 
writing head uses a 5 mW red laser, and can focus to a spot 
smaller than .001". I actually defocus it slightly so the 
raster lines blend together.
It uses a microfiche objective lens plus a double-meniscus 
lens and a 2mm sphere lens right against the laser.  Similar 
optics could be used for a read head.  It would not be real 
hard to make a version like this to scan microfiche, 
scanning the entire card at once.


Not sure that LEDs would work, but red lasers are just a 
couple $ now.


Jon


Speed now & then

2018-03-29 Thread Murray McCullough via cctalk
I’m not trying to date myself but have things truly sped up? In 1970’s
Toronto I had a classic computer, sorry can’t recall what it was, connected
to a 300 baud modem; by early 80’s had ‘zoomed’ to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I’m at 5MB/s. Yikes! (Friends in Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray  -:)


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread emanuel stiebler via cctalk
On 2018-03-29 06:27, Peter Coghlan via cctalk wrote:

> On my machine, the mini console memory test reports that all the memory is
> bad in pretty much all locations and the errors are different each time I
> run the test.  I think it is extremely unlikely that all the memory has
> gone
> bad simultaneously so I think I should investigate other possible
> causes.  In light of the cache errors uncovered on my 600, 
> I wonder if bad cache could be the culprit here too.  

It would defeat the purpose of a RAM test, using the caches ;-)

> Or maybe there is no power to the SIMM slots or
> something else silly like that.  I think I need to do some further digging.

Reseat them, test one by one, ...

Drivers gone, power to the modules


Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Maciej W. Rozycki via cctalk
Hi Peter,

> J8 (position 0) is where the jumper already is on both my 3000 600 machines.
> It is possible that this is where it normally is, however, it is also possible
> that I moved it there some time ago in an attempt to diagnose the problem and
> I have since forgotten.  Which position is the jumper at in your system?

 It's in at position 0 (J8), as per documentation.

> Anyway, you spurred me on to try moving it to some of the other positions.
> When I place it at J3 (position 5), I get this:
> 
> DEC 3000 - M600 SROM 6.1
> Mfg Test
> ff.fd.fb.f0.
> MCRstat .808011c0
> bnkSize 0300.0c01
> memSize 00c0.00c0
> 
> memTest (no-cache)
> LongWord Memory Test
> 
> done.
> done.
> done.
> 
> The last line repeats approximately every minute or so, possibly indefinately.
> 
> However, when I place the jumper at J2 (position 6), I get this:
> 
> DEC 3000 - M600 SROM 6.1
> Mfg Test
> ff.fd.fb.f0.
> MCRstat .808011c0
> bnkSize 0300.0c01
> memSize 00c0.00c0
> 
> memTestCacheOn
> LongWord Memory Test
> 
> address:0bf7dad8 wrote: read:ddee
> address:0bf7da58 wrote: read:ddee
> address:0bf7d8d8 wrote: read:ddee
> address:0bf7d858 wrote: read:ddee
> address:0bf7d2d8 wrote: read:ddee
> address:0bf7d258 wrote: read:ddee
> address:0bf7d0d8 wrote: read:ddee
> 
> ... followed by many many similar lines.  It looks like I have cache problems.

 These must be the alternative diagnostic routines mentioned the system 
programmer's manual:

"A DECchip 21064-AA CPU, including on-chip 8-KB instruction and 8-KB data 
caches, and a 64-KB serial boot ROM.  A 64-KB stream holds the primitive 
boot code for booting the operating system.  Jumpers provide for the 
selection of up to seven other streams for diagnostic and other purposes. 
(The entire UVPROM is 64 K x 8.)"

> Thanks but in light of my cache problems, it looks like I need to deal with
> those first.  Perhaps the SYSROM is getting copied into main memory but when
> the in-memory copy is read for execution, garbage is returned due to the cache
> errors, leading to the system hanging with F0 on the diagnostic LEDs?  
> However,
> according to one of the manuals (but not the other!), cache errors should have
> been detected before the LEDs counted down as far as F0.

 I take it F0 is the last output from SROM before handing control over to 
SRM.  Now that you've got a way to see SROM diagnostic output directly I 
would expect these codes not to matter as much anymore.

  Maciej


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Al Kossow via cctalk


On 3/29/18 7:54 AM, emanuel stiebler via cctalk wrote:

> That's why we should do it now, not later ;-)
> 

If people in the Bay Area has the time to work on this, they can have
access to my scanners in my lab. I brought one up a couple of years ago.
The problem with any micrographics equipment is that the documentation
(esp harware) sucks and the real service manuals are  impossible to get.

It is going to be a SERIOUS time commitment, though.

I will put some pictures of them up on bitsavers.org/projects/microfiche
later today.



Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Douglas Taylor via cctalk

On 3/29/2018 8:27 AM, Peter Coghlan via cctalk wrote:


I have a functioning Alpha 3000 300, perhaps it can help with some of 
the questions you have.

Doug



Many thanks for the offer Doug.  However, I can't think of anything I can
ask you to do right now.

On my machine, the mini console memory test reports that all the 
memory is

bad in pretty much all locations and the errors are different each time I
run the test.  I think it is extremely unlikely that all the memory 
has gone
bad simultaneously so I think I should investigate other possible 
causes.  In
light of the cache errors uncovered on my 600, I wonder if bad cache 
could

be the culprit here too.  Or maybe there is no power to the SIMM slots or
something else silly like that.  I think I need to do some further 
digging.


Regards,
Peter Coghlan.


I enjoy eavesdropping on this conversation, it has made me aware of 
something I didn't know about the machines I have in my collection.


Doug



Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Al Kossow via cctalk
also aperture cards, which are punched cards with a single 35mm image on them

On 3/29/18 8:49 AM, Al Kossow via cctalk wrote:
> yes, IBM fiche is the size of a punched card
> 
> In theory, the scanner I bought should be able to handle it if I
> can make custom carriers for it.
> 
> On 3/29/18 6:16 AM, emanuel stiebler via cctalk wrote:
>> Stupid question on the side, as I know/have DEC fiche only.
>> Are there any fiche out there, which are bigger than 8x6 inches?
>>
> 



Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Al Kossow via cctalk
yes, IBM fiche is the size of a punched card

In theory, the scanner I bought should be able to handle it if I
can make custom carriers for it.

On 3/29/18 6:16 AM, emanuel stiebler via cctalk wrote:
> Stupid question on the side, as I know/have DEC fiche only.
> Are there any fiche out there, which are bigger than 8x6 inches?
> 



Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread geneb via cctalk

On Thu, 29 Mar 2018, et...@757.org wrote:

I'm probably WAY over simplifying this because I don't have a grasp of the 
optics involved, but wouldn't it be possible to get a good image of 
individual pages on a microfiche by using a DSLR with the right lens and a 
CNC X/Y table made from one of the large (8x10) LED illuminators used to 
treat SAD?  The lights are pretty bright and are under $50.  The X/Y table 
build would be very simple and cheap to build.  The only "real" expense 
would be the right lens on the camera.


Yep. That is what I was thinking originally. I wasn't against the idea of 
projecting the slide to a surface then capturing that.


I wasn't thinking about projecting it, I was referring to direct imaging 
using a macro(?) lens on the camera.


g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Ethan via cctalk
I'm probably WAY over simplifying this because I don't have a grasp of the 
optics involved, but wouldn't it be possible to get a good image of 
individual pages on a microfiche by using a DSLR with the right lens and a 
CNC X/Y table made from one of the large (8x10) LED illuminators used to 
treat SAD?  The lights are pretty bright and are under $50.  The X/Y table 
build would be very simple and cheap to build.  The only "real" expense would 
be the right lens on the camera.


Yep. That is what I was thinking originally. I wasn't against the idea of 
projecting the slide to a surface then capturing that.


There is a Canon 300 something or other Microfiche machine on eBay. 
They're like $200-300. It's a viewer that supports computer capture via 
what looks like SCSI and Twain driver. 5.5 seconds per grab:


Oh look here is a DIY one that is good enough to center it on each page. 
Impressive. I think he is scanning DEC information:

https://www.youtube.com/watch?v=GCRr9sbHBnM

Here is the Canon 300II:
https://www.youtube.com/watch?v=Ro1pO5Zd9hI

I'm not sure how person from unit #1 centers it, but unit #2 with a 
autoloader and steppers to do X/Y I think might provide sexy output.


The process could be automated by using a cheap SMD part vacuum (the little 
hand-held one I have ran about $10) attached to an arm that was run by some 
R/C servos.


That is what I was thinking, but there might be cases where the slide 
sticks to the top of the glass holder. I think the holder is important for 
focus.




--
: Ethan O'Toole




Re: OT: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Paul Koning via cctalk


> On Mar 28, 2018, at 11:39 PM, Fred Cisin via cctalk  
> wrote:
> 
> On Wed, 28 Mar 2018, Bob Rosenbloom via cctalk wrote:
>> This thread reminded me of a DYI scanner I had read about. Found it with 
>> google:
>> http://retrocmp.com/projects/scanning-micro-fiches/235-the-homebuild-automatic-micro-fiche-scanner
> 
> I like his enthusiasm and the fact that he actually got it together and DID 
> it.
> 
> Hmmm.  If you gut the reader, and photograph the illuminated portion of the 
> fiche, rather than project and photograph the screen, image quality will be a 
> lot better.  Ambient light will cease to be a significant issue.
> 
> I don't think that ANY of them are color, so with bitonal, noise should not 
> be that much of a problem, unless that is being compounded by the long 
> exposure?  

That sounds right for documentation microfiche such as the DEC ones.

I've run into microfiche that is somewhat similar but for a very different 
purpose: the rear-projection microfiche used in PLATO terminals.  Those have 
square images, 256 of them (16 by 16).   And they often are in color.  They 
were used to provide photo images to go with the bitonal (orange/black) PLATO 
screens, for applications such as teaching botany.

paul




SGI SN-921 dial box (978-0804) (was Re: IBM 6094-010 "Dials" protocol?)

2018-03-29 Thread Ethan Dicks via cctalk
On Sun, Mar 25, 2018 at 6:09 PM, Ethan Dicks  wrote:
>> SN-921 (2.1mm barrel jack for +5V)
>>   
>> https://upload.wikimedia.org/wikipedia/commons/7/74/Sgi_dialbox_sn-921_front.jpg
>
> http://yehar.com/blog/?p=3471
>
> The (Seiko?) SN-921 can apparently be powered via DE9 or the 2.1mm
> jack next to it...
>
> 1. GND
> 2. SERIAL OUTPUT (±9 V)
> 3. SERIAL INPUT
> 4. POWER IN +5 V
> 5. POWER IN +5 V
> 6. NC
> 7. NC
> 8. GND
> 9. NC

Now that I've poked around in the innards, I can say that this pinout
has a slight mistake in it.  It should be:

1. GND
2. SERIAL OUTPUT (±9 V)
3. SERIAL INPUT
4. POWER IN +5 V
5. POWER IN +5 V
6. NC
7. GND
8. NC
9. NC

There are mentions here and there about how to hook up this dial box
using the +5V power jack and DE9 pins 2, 3, and 7.  I can confirm from
direct examination that pin 7 is a ground and 8 is NC on the PCB (and
that 4 and 5 are connected directly to the center pin of the 2.1mm
power jack).

-ethan


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread emanuel stiebler via cctalk
On 2018-03-28 22:26, Shaun Halstead via cctalk wrote:
> All of the DEC film I
> have (which I believe is already available) is diazo duplicates, which are
> susceptible to fading over time, even when stored in proper conditions.

That's why we should do it now, not later ;-)


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread geneb via cctalk

On Wed, 28 Mar 2018, Zane Healy via cctalk wrote:


The Illumitran uses bellows, but for a lot of DEC fiche, the page size is 
constant so extension tubes might actually be better - they won't slip.


Initially I was going to suggest an Illumitran, but I don’t think it 
would work that well with trying to move the fiche around. You might 
have a point on the DEC fiche, though the bellows will allow you to 
maximize your page size.  Of course that may not be the greatest idea, 
as the more you maximize the size, the more attention you’ll have to pay 
to positioning each frame.


I'm probably WAY over simplifying this because I don't have a grasp of the 
optics involved, but wouldn't it be possible to get a good image of 
individual pages on a microfiche by using a DSLR with the right lens and 
a CNC X/Y table made from one of the large (8x10) LED illuminators used to 
treat SAD?  The lights are pretty bright and are under $50.  The X/Y table 
build would be very simple and cheap to build.  The only "real" expense 
would be the right lens on the camera.


The process could be automated by using a cheap SMD part vacuum (the 
little hand-held one I have ran about $10) attached to an arm that was run 
by some R/C servos.


You could use a webcam to image the whole sheet in order to obtain the 
title of the sheet and that image along with the individual page images 
could be stored together.  The webcam could also be used in conjunction 
with OpenCL to ensure that the fiche positioner got it right every time.


g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread emanuel stiebler via cctalk
Stupid question on the side, as I know/have DEC fiche only.
Are there any fiche out there, which are bigger than 8x6 inches?


Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Peter Coghlan via cctalk


I have a functioning Alpha 3000 300, perhaps it can help with some of 
the questions you have.

Doug



Many thanks for the offer Doug.  However, I can't think of anything I can
ask you to do right now.

On my machine, the mini console memory test reports that all the memory is
bad in pretty much all locations and the errors are different each time I
run the test.  I think it is extremely unlikely that all the memory has gone
bad simultaneously so I think I should investigate other possible causes.  In
light of the cache errors uncovered on my 600, I wonder if bad cache could
be the culprit here too.  Or maybe there is no power to the SIMM slots or
something else silly like that.  I think I need to do some further digging.

Regards,
Peter Coghlan.


Re: DEC 3000 (alpha) faultfinding

2018-03-29 Thread Peter Coghlan via cctalk
Hi Maciej,

>
> "DEC 3000 Models 600/600S AXP and 800/800S AXP Service Information",
> Order Number: EK-FLSPC-SV. A01 (flspcsva.pdf) seems to indicate on page
> 2-2 that the SROM console jumper is one in position 0 among the SROM
> jumpers whose location is shown in the figure on that page.  I have
> checked my /700 (which is the same as the /600 except for a faster CPU)
> and this is also marked J8 on the PCB.
>

Many thanks for the pointer to EK-FLSPC-SV - I had not come across this
manual and it contains lots of useful information that is not in EK-D3SYS-PM.
I have some reading to do.  Interestingly, there are significant differences
in the descriptions of the diagnostic LED codes between the two manuals and
neither of them seems to describe exactly what I am seeing.

J8 (position 0) is where the jumper already is on both my 3000 600 machines.
It is possible that this is where it normally is, however, it is also possible
that I moved it there some time ago in an attempt to diagnose the problem and
I have since forgotten.  Which position is the jumper at in your system?
Anyway, you spurred me on to try moving it to some of the other positions.
When I place it at J3 (position 5), I get this:

DEC 3000 - M600 SROM 6.1
Mfg Test
ff.fd.fb.f0.
MCRstat .808011c0
bnkSize 0300.0c01
memSize 00c0.00c0

memTest (no-cache)
LongWord Memory Test

done.
done.
done.

The last line repeats approximately every minute or so, possibly indefinately.

However, when I place the jumper at J2 (position 6), I get this:

DEC 3000 - M600 SROM 6.1
Mfg Test
ff.fd.fb.f0.
MCRstat .808011c0
bnkSize 0300.0c01
memSize 00c0.00c0

memTestCacheOn
LongWord Memory Test

address:0bf7dad8 wrote: read:ddee
address:0bf7da58 wrote: read:ddee
address:0bf7d8d8 wrote: read:ddee
address:0bf7d858 wrote: read:ddee
address:0bf7d2d8 wrote: read:ddee
address:0bf7d258 wrote: read:ddee
address:0bf7d0d8 wrote: read:ddee

... followed by many many similar lines.  It looks like I have cache problems.
Maybe there is a way to disable the various caches and see if it works then.
This reminds me of my Alphaserver 1000A machines and their cache failures :-(

>
>> The 600 machines have a socketed 27C512 EPROM.  I assume this must be the 
>> SROM
>> (although I can't see what is serial about it) as the machines fail to update
>> the diagnostic LEDs or write to the mini console if it is removed.  I dumped
>> the two EPROMs and compared them and they are identical.  However, I can't 
>> see
>> any ASCII strings in them.  Perhaps the bits are not used in the standard
>> order?  The manual suggests that there are 8 different 8KB SROM images 
>> present
>> and those other than the "standard" one may be used for testing and 
>> diagnostics
>> by setting jumpers. Unfortunatly, there is no further information about these
>> images.
>
> The location of the SROM chip is also shown in the figure on page 2-2.
>

This show the location of the 27C512 EPROM in my systems so I guess it must be
the SROM.

>
>> The format of the headers in the SYSROM and IOROM do not exactly match the
>> format given in the manual but they are "close".  I wonder if this might
>> be my problem or if the manual is incorrect.  If anyone else has a 3000 600,
>> could they take a peek at their SYSROM and maybe we could compare notes?
>
> I could check my /700 with SRM.  What would you like me to look at?
>

Thanks but in light of my cache problems, it looks like I need to deal with
those first.  Perhaps the SYSROM is getting copied into main memory but when
the in-memory copy is read for execution, garbage is returned due to the cache
errors, leading to the system hanging with F0 on the diagnostic LEDs?  However,
according to one of the manuals (but not the other!), cache errors should have
been detected before the LEDs counted down as far as F0.

>
> Hope this helps.  Good luck with your fault debugging.
>

It was very helpful.  Many thanks.

Regards,
Peter Coghlan.

>
>  Maciej
>


Re: RAID? Was: PATA hard disks, anyone?

2018-03-29 Thread Peter Corlett via cctalk
On Wed, Mar 28, 2018 at 05:40:29PM -0700, Richard Pope via cctalk wrote:
> I have been kind of following this thread. I have a question about MTBF. I
> have four HGST UltraStar Enterprise 2TB drives setup in a Hardware RAID 10
> configuration. If the the MTBF is 100,000 Hrs for each drive does this mean
> that the total MTBF is 25,000 Hrs?

That's the mean time before any one disk fails, but not the MTBF for the array
as a whole because failure of an individual disk doesn't cause the array to
fail. There needs to be at least one more disk failure for that to happen.

MTBF is also an overly simple measure which fails to account for the bathtub
curve and correlated failures. Attempts to compute the MTBF of an array from
the MTBF of the individual components will come up with a plausible number
which is technically correct yet bears no relation to the real world.

In practice, the only numbers on a typical hard disk datasheet which aren't
fantasy marketing puff are the physical dimensions and the number of sectors,
and even that is because those are industry-wide standards that disks must
conform to.



Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Pete Turnbull via cctalk

On 29/03/2018 05:26, Shaun Halstead via cctalk wrote:


Using the wrong filament orientation can cause some weird artifacts
to appear on scanned images, because of the high magnification. I
strongly suspect that an attempt using an LED source would face
similar (and possibly worse) issues.


Light source.  Due to lensing requirements, LED's are probably out, 
unless a way can be found to suitably diffuse or blend the source 
without losing significant light.  This requires a very strong light 
source.


Yet there are plenty of LED light sources used in photomicroscopy so I
don't believe it's that hard to do,which is why I suggested it.  I've 
seen it done with a high-brightness 5mm LED, but if a bit more "oomph" 
or a larger emitting area is required, there are inexpensive 1W and 3W 
LEDs that look like they'd work.  I'm no expert, but the biggest problem 
in photomicroscopy seems to be the spectrum, which isn't really an issue 
for monochrome microfiche.


--
Pete
Pete Turnbull


Re: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread Pete Turnbull via cctalk

On 29/03/2018 03:15, Zane Healy wrote:


More and more, I view my Classic Computer collection as a hinderance
to building a proper darkroom.  Oddly enough, the main purpose of my
PDP-11/44 these days is to hold a couple old enlargers that I don’t
use.


LOL!  I wish I still had my De Vere 5x4 enlarger, but I've nowhere to 
put such a thing.  Anyway, although I have access to some 5x4 Sinar 
equipment, the largest format I still have of my own is a couple of 
Mamiya 645s.


OT anecdote: Some years ago a colleague asked if I'd take her wedding 
photos.  I used to dislike doing that in the 70s and 80s so I wasn't 
keen on taking the hundreds of shots that seem to be the modern fashion. 
 She persisted, so I said I would if she bought me the 22 megapixel 
digital back for my Mamiya 645 Pro.  OK, she said, so I suggested she 
ought to check the price, after which she declined :-)


--
Pete
Pete Turnbull


Re: Looking for opinions...

2018-03-29 Thread Noel Chiappa via cctalk
> From: Liam Proven

> And yet, 3 generations later

Can we please keep _all_ politics off the list? It didn't go so well
last time.

Noel


Re: OT: Digitising collections of microfiche - Re: Looking for opinions...

2018-03-29 Thread emanuel stiebler via cctalk
On 2018-03-28 20:59, Bob Rosenbloom via cctalk wrote:
> On 3/28/2018 6:00 PM, Fred Cisin via cctalk wrote:
 If you start with a fiche viewer, then a lot of the mechanical
 parts, such as the fiche holder, are well under way.  You need to
 modify the card movement mechanism to be able to automate it, but
 you could put that part off until you confirm that the optical
 portion is satisfactory.
> ...snip
> This thread reminded me of a DYI scanner I had read about. Found it with
> google:
> http://retrocmp.com/projects/scanning-micro-fiches/235-the-homebuild-automatic-micro-fiche-scanner

The last sentence says it all:
"And I'll think twice before I scan another batch of fiches!"