Re: Apollo Date Bug

[Kurt Nowak via cctalk]

Well actually I didn't rescue them - they belonged to my father so i guess
you can say I inherited them. He was a physicist and did quite a bit of
Fortran development on them years ago. I worked with Suns at the time and
so our worlds kind of merged and I ended up helping him with some problems
he had and ended up learning some things about Apollos in the process. Plus
he had a pretty decent documentation collection too which was very helpful.
Eventually when he saw the end days for Apollo he scooped up all of the
machines he could find and hoarded them away. He even managed to get ahold
of the Apollos at the Scripps Institute of Oceanography lab when they
scrapped them. I think i have about 15 of them in various states and I have
a decent collection of spare parts.  I did get rid of the monitors though
since they were too much to deal with and they output fine on
my flat-screen monitors with the right cabling. But yeah there sure doesn't
seem to be very many people out there that have them anymore for whatever
reason...Not the most attractive boxes and they are heavy as hell too!

On Thu, Apr 8, 2021 at 4:59 AM Jules Richardson via cctalk <
cctalk@classiccmp.org> wrote:

> On 4/7/21 1:16 AM, Kurt Nowak via cctalk wrote:
> > Hi All,
> >
> > Back after a long time away from this list... I happen to have a small
> herd
> > of Apollo DN3500/4500 boxen which i pulled out the other day to see if
> they
> > still run.
>
> I can't help with the date issue, but just wanted to say how nice it is to
> hear that someone out there has rescued some Apollo stuff - there was
> someone in one of the other vintage groups I'm in a couple of years back
> who'd found one of their early machines (dn400 I believe), but that's the
> only time I think I've seen mention of them in a very long time.
>
> I had access to a lab of 9000/425 machines in the mid 90s and that's what
> got me hooked, then when I was at TNMoC prior to my moving over to the US
> we had some 2500/3000/4000 systems that I looked at, but sadly those had
> spent some time in damp conditions and weren't ever likely to work again -
> the corrosion was just too bad.
>
> Jules
>

Re: Lisa Source Code

[Richard Sheppard via cctalk]

I believe the original Amiga file system also used a linked-list approach. That 
way you could, theoretically, reconstruct a file from any one of it’s data 
blocks.
Richard

Sent from Mail for Windows 10

Re: RSX11D disks on EBAY- anyone interested?

[Noel Chiappa via cctalk]

> From: Jerry Weiss

> I always wondered why the RKV11-D was only 16 bit addressable.

The manual (EK-RKV11-OP-001) says: "Since the 11/03 BUS structure has no
provision for extended addressing, no connection is made to the bus from
these [XM] bits on the RKVII-D." (pg. 3-5).

> The DEC RK05 disk subsystem cost $10K list circa 1978 (drive, RKV-11D
> controller and cabinet), so this wasn't a trivial purchase.

Interesting. Where did you see that listed, just out of curiosity? (I looked
in the Jan '84 PDP-11 Systems and Options, my copy of which just showed up,but
that's too late; I could probably find it if I pawed through all my DEC sales
literature, but I'm too lazy... :-).

Noel

Re: Lisa Source Code

[Chuck Guzis via cctalk]

On 4/8/21 12:43 PM, John Foust via cctalk wrote:
> At 02:27 PM 4/8/2021, Chuck Guzis via cctalk wrote:
>> By the way, does anyone know the structure of an ".ITI" file
> 
> The context is a WORM file system, or a particular OS, or an app environment?
> 

Files extracted from a WORM file system; OS not relevant according to
documentation that I have (same product offered for several different
platforms).  App appears to be some sort of document archiving system.

Said files contain no recognizable cleartext.

Ring any bells?

--Chuck

Re: Lisa Source Code

[John Foust via cctalk]

At 02:27 PM 4/8/2021, Chuck Guzis via cctalk wrote:
>By the way, does anyone know the structure of an ".ITI" file

The context is a WORM file system, or a particular OS, or an app environment?

- John

Re: Lisa Source Code

[Chuck Guzis via cctalk]

On 4/8/21 11:38 AM, Antonio Carlini via cctalk wrote:

> But (afaict) a sector that has never been written is just that:
> unwritten. How does it convey any information (other than "I'm still
> blank")?

Let me try...

Because you can't rewrite or update tables without copying them, a WORM
file system that can be updated dynamically has to resort to lists of
previous versions of the tables.  So to find the most recent copy of any
list, you read through the list until one of two things happens:  You
hit an unwritten sector, which means that the last thing read
successfully is what you're after, or the preallocated list area is
completely full, in which case the list continues in another
preallocated area or is at the absolute end, depending on the
implementation.

In the WORM file system that I'm currently working in, the
implementation is a mixture of both.   There are fixed preallocated
areas for directory information, but there are also lists of file data
areas written that can overflow to other preallocated areas.

Overflow of the directory is handled with a tree structure, so it's
pretty much the same thing as a linked list in a practical sense.

I assume that it was done that way so that a bad (error) sector wouldn't
upset the whole apple cart.

By the way, does anyone know the structure of an ".ITI" file?

--Chuck

Re: Lisa Source Code

[Antonio Carlini via cctalk]

On 08/04/2021 17:29, Chuck Guzis via cctalk wrote:

On 4/8/21 8:40 AM, Eric Smith wrote:

On Thu, Apr 8, 2021, 09:34 Chuck Guzis mailto:ccl...@sydex.com>> wrote:

 There's a big difference--in a WORM, unwritten sectors *mean* something.


For archival purposes, in what way does an unwritten sector on a WORM
mean more than an unwritten sector (with no data field present) of a
floppy? Neither can be accurately archived without representing the fact
that it is unwritten.

Simple--a WORM contains the entire history of information on the disc;
nothing is ever lost.  A floppy can have data overwritten--and probably
does (e.g. directories and allocation maps)  The only way to update a
WORM is to add to it.

I must be missing something. I understood (for WORM) "unwritten" to mean 
"never written" rather than "written but its address is no longer in the 
FS catalogue".


So with WORM (whether DEC RVxx style optical disk or CD/DVD-RW in 
certain modes) you can (if the firmware allows) read sectors that 
contain stale data.


But (afaict) a sector that has never been written is just that: 
unwritten. How does it convey any information (other than "I'm still 
blank")?



Antonio


--
Antonio Carlini
anto...@acarlini.com

Re: Lisa Source Code

[Chuck Guzis via cctalk]

On 4/8/21 8:40 AM, Eric Smith wrote:
> On Thu, Apr 8, 2021, 09:34 Chuck Guzis  > wrote:
> 
> There's a big difference--in a WORM, unwritten sectors *mean* something.
> 
> 
> For archival purposes, in what way does an unwritten sector on a WORM
> mean more than an unwritten sector (with no data field present) of a
> floppy? Neither can be accurately archived without representing the fact
> that it is unwritten.

Simple--a WORM contains the entire history of information on the disc;
nothing is ever lost.  A floppy can have data overwritten--and probably
does (e.g. directories and allocation maps)  The only way to update a
WORM is to add to it.

--Chuck

Re: Lisa Source Code

[Chuck Guzis via cctalk]

On 4/8/21 12:23 AM, Eric Smith wrote:
> On Wed, Apr 7, 2021 at 2:33 PM Chuck Guzis via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
> 
> Okay, I've got a WORM disc here--how do they propose to archive that?
> (recall that unwritten sectors can't be read).

There's a big difference--in a WORM, unwritten sectors *mean* something.
  Recall that you can't ever re-write or erase data.   The read/write
filesystems are "interesting" and use the presence or absence of data as
part of the picture.

Just unraveled one such filesystem--it's interesting.  You never lose
information.

Consider that, on a sector basis, there are three possibilities for the
value of a bit.


--Chuck

Re: DEC H8575-A DB25 to MMJ

[John H. Reinhardt via cctalk]

On 4/7/2021 10:37 PM, Ron Pool via cctalk wrote:

I found some more DEC MMJ crimpers that look pretty decent out there on eBay, 
but they're not well labelled.

https://www.ebay.com/itm/Ideal-30-558-Crimp-Die-for-RJ-11-MJ-Modular-Plug-Crimpmaster-Tool-Frame-30-506/333697351548
 $15 plus shipping new (2 avail) MMJ die for ideal crimp frame 30-506.

There are new and used Ideal 30-506 frames on eBay for reasonable prices.  Search for 
"Ideal 30-506".

https://www.ebay.com/itm/Ideal-Twisted-Pair-Kit-33-650-w-Plugs-and-30-506-30-559-30-560-30-558-Dies/265100183244
 $55 plus shipping used kit (2 avail) including above die, other dies, and 
30-506 crimp frame plus cable cutter and stripper.

https://www.ebay.com/itm/IDEAL-TWISTED-PAIR-KIT-45-074/301901645725 $55 free 
ship in US used Ideal kit (without case) similar to above including DEC MMJ and 
other dies and tools, but of a different vintage

And it could be worth searching for Crimpmaster instead of Ideal.  There are 
lots of used Ideal Crimpmaster frames with dies, but not all of them include 
Ideal in the description.  Maybe some of them are DEC RJ-11 MMJ.

 -- Ron Pool





The Ideal Crimpmaster tool looks a lot like the Paladin / Greenlee / Tempo 
tool.  It may be that the Ideal dies will fit.



A search of the Ideal site finds no mention of the 30-558 RJ11 MJ crimp die 
though so perhaps it's out of production there as well. If you find one and 
want it, get it as who knows if they will be available again.

--
John H. Reinhardt

Looking for VAXSET Software Engineering Tools for VMS 4.x

[Malte Dehling via cctalk]

Dear all,

I am looking for a version of the VAXSET Software Engineering Tools to
run on (Micro)VMS 4.7.  The oldest version I have found so far is
VAXSET010 which requires VMS 5.3 to run (this was on CSD 1991/05.)

VAXSET is a bundle of the following components (and more in newer
versions):
- CMS (Code Management System)
- LSE (Language Sensitive Editor)
- SCA (Source Code Analyzer)
- MMS (Module Management System)
- PCA (Performance Coverage Analyzer)
- DTM (DEC/Test Manager)

I have found versions of CMS and MMS seperately that run on VMS 4.x.  If
anyone has old versions of the other components and is willing to share,
that would be much appreciated :-)

Cheers,
Malte


-- 
Malte Dehling

Re: Apollo Date Bug

[Jules Richardson via cctalk]

On 4/7/21 1:16 AM, Kurt Nowak via cctalk wrote:

Hi All,

Back after a long time away from this list... I happen to have a small herd
of Apollo DN3500/4500 boxen which i pulled out the other day to see if they
still run. 


I can't help with the date issue, but just wanted to say how nice it is to 
hear that someone out there has rescued some Apollo stuff - there was 
someone in one of the other vintage groups I'm in a couple of years back 
who'd found one of their early machines (dn400 I believe), but that's the 
only time I think I've seen mention of them in a very long time.


I had access to a lab of 9000/425 machines in the mid 90s and that's what 
got me hooked, then when I was at TNMoC prior to my moving over to the US 
we had some 2500/3000/4000 systems that I looked at, but sadly those had 
spent some time in damp conditions and weren't ever likely to work again - 
the corrosion was just too bad.


Jules

Re: Lisa Source Code

[Eric Smith via cctalk]

On Wed, Apr 7, 2021 at 2:33 PM Chuck Guzis via cctalk 
wrote:

> Okay, I've got a WORM disc here--how do they propose to archive that?
> (recall that unwritten sectors can't be read).
>

Same for Apple DOS 3.1, 3.2, and 3.2.1 (13-sector format). The formatter
only writes the address fields, but no data fields. Apple fixed that (if
you consider it a defect) in the 16-sector format (DOS 3.3, Pascal, SOS,
ProDOS, GS/OS).