Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread dwight via cctalk
By the way, how is the terminal and keyboard connected to the computer?

Is it by RS232?

If so, it might be through SIO B. If this is the case, it might be the problem.

Also, the RAM failure may be the issue as well. You have something that is 
intermittent there. Bad RAM can cause programs to misbehave as well. Just 
because it passes some times doesn't mean it is good enough to run programs.

Dwight



From: cctalk  on behalf of dwight via cctalk 

Sent: Tuesday, October 17, 2017 4:08:46 PM
To: Dominique Carlier; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette 
subsystem : Restoration

Since you know the pinout of the SIO chip, you might first look to see if where 
the rx and tx pins go. This may require some hunting with an ohm meter. I'd 
suspect they go to a RS232 level shifter.

You may also have to write some code to run the serial chip and any possible 
external loopback. As I recall these chips may have an internal loopback.

If you have a working logic analyzer, you can trigger on the select pin to the 
SIO and look to see what address the SIO is located at. That will allow you to 
create some debug code.

I'm not saying this is easy. Still, this is the way I'd attack the problem as a 
start.

You have to realize, there is not much more we can do for you.

Creating a ROM with a diagnostic looping program is about the only practical 
way to deal with a machine with no documentation.

I fixed an old mini once without schematics but it was all DTL and TTL and 
there were signal names at the card edges.

You have a Z80 computer. If you can program EPROMs you have a chance, otherwise 
it is unlikely that your current easter egg hunting method is likely to be very 
fruitful. You have already gone through most all of the likely failure items. 
From here you will likely have to begin to troubleshoot.

Dwight



From: cctalk  on behalf of Dominique Carlier via 
cctalk 
Sent: Tuesday, October 17, 2017 1:59:47 PM
To: Chuck Guzis; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette 
subsystem : Restoration

Thanks for your response Chuck,

As described in the topic, just after the Power On, the machine runs a
self-test which is called "POC TEST" on the UTS range of Sperry Univac.
During this test, the machine checks the status of the RAM, the ROMs,
the Counter Timer, and the various communication interfaces.
Everything is OK except the ninth line which says: "SERIAL I / O CHANNEL
B: FAILED"

(ignore the FAILED next to "OPTIONAL RAM BANK 0,1", the machine can
start without this board)
http://www.zeltrax.com/classiccmp_forum/uts40_screen03.jpg

This channel B error completely freezes the machine, it does not load
the default settings, I no longer have access to the setup page, in this
situation the keyboard remains without effects.

When the POC test is successful, it loads the default settings in non
volatile RAM:
http://www.zeltrax.com/classiccmp_forum/uts40_screen01.jpg

And I can access the setup page:
http://www.zeltrax.com/classiccmp_forum/uts40_screen02.jpg

The few times I was able to go into the setup page (CHANNEL B: PASSED),
I rushed to try to encode (with the dead keyboard) the data to declare
the subsystem and finally return to the CP/M mode. And I had twice the
case where without warning hop! Blank screen, automatic reset, self-test
(POC) -> SERIAL I / O CHANNEL B: FAILED (again).
Maybe we have there some interesting information about the problem, the
intermittent nature of this failure, could this give information about
the type of component in fault?

But note that since weeks now the problem has become permanent, I have
never been able to return to this famous setup page and the "serial I/O
channel B" is now always marked as 'FAILED'.

So I have no way to try anything using the terminal at this point.

It is possible that the breakdown is in fact very simple (dry solder dry
or attacked solder by the acid of the battery), but I would like to
avoiding to rework all the solders, and maybe to finally find that the
problem was at the level of an IC, I would try to locate the components
linked to this problem. I look at the SIO, try to discover what is after
just after, see how I can eventually act on the pin 30 (W/RDYB) of that IC :
http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg


And try to understand why this SIO no longer considers the channel B as
'READY'
This kind of things ...
There are probably programmable loop-back circuitry used by the POC test
program (in the ROM of the program cartridge).To ignore the negative
diagnostic I would like to induce to the self-test program that the
channel B is OK, what should I inject to the SIO (perhaps on this pin
30) to 

Interdata 70 front panel keys

2017-10-17 Thread Josh Dersch via cctalk

Hi all --

Got an Interdata Model 70 here (well, the parts to build one, anyway) 
missing the front panel key.  Anyone (a) got a few spares lying around 
or (b) have key codes for this thing?


Thanks,

Josh



Decus tape

2017-10-17 Thread jim stephens via cctalk
I wonder if anyone knows where the actual content of these tapes are 
located?


I have a Digital Pathways TCU 50-D card which requires a couple of 
routines, and figured it was worth asking while searching.


http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/110625.html

10625 TCUGET/TCUPUT Digital Pathways TCU-50D I/O  Version:
January 1981
 
Submitted by: Bruce D. Sidlinger, Software Science/Software Art, San

Antonio, TX

Next higher index of the library index

http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/index.html

This tape index has the first hit in a complete tape:

http://compendium.decuslib.com/decus/vax000/rt83a.lis

First task will examining the three battery modules on board and 
replacing if necessary.


Thanks
Jim




Re: Anyone in Canada (preferably BC) running RSX?

2017-10-17 Thread Jon Elson via cctalk

On 10/17/2017 03:00 PM, Chuck Guzis via cctalk wrote:

I've just received a query from an outfit in BC who has a few (<10) RSX
(apparently) either RX01 or RX02 floppies that they'd like to extract
the files from.


I think you can do this on a VAX 780 through the console 
floppy drive.  Any other VAX that has a media-compatible 
floppy drive ought to be able to read it, also.  You might 
have to use the foreign option when mounting it.


Jon


Re: Visicalc

2017-10-17 Thread Peter Cetinski via cctalk

> On Oct 17, 2017, at 7:24 PM, Fred Cisin via cctalk  
> wrote:
> 
>> On 17 October 2017 at 22:51, Murray McCullough via cctalk
>>  wrote:
>>> Today marks the 36 anniversary of Visicalc a seminal program in the
>>> world of classic computing.
>>> Happy computing!
>>> Murray  :)
> 

It’s a little bit older than 36, right?


From the first TRS-80 Model II edition of Visicalc manual:

First Edition

TRSDOSTM Operating System: 

1979, 1980 Tandy Corporation All Rights Reserved.

VisiCalcTM Program:

© 1980 Software Arts, Inc.

Manufactured by Personal Software Inc.

Exclusively for Tandy Corporation.

All Rights Reserved.

"VisiCalcTM Program Manual":

'' 1980 Personal Software Inc.

All Rights Reserved.




Re: HP 7970 1/2" 9-Track Reel-to-Reel Tape Drive...

2017-10-17 Thread David Collins via cctalk
Pretty expensive to ship one from Australia I guess...

David Collins


> On 18 Oct 2017, at 6:34 am, Jack Harper via cctalk  
> wrote:
> 
> 
> Greetings to the List -
> 
> Does anyone know of a HP 7970 (any model) tape drive that might be 
> available
> 
> Any leads appreciated.
> 
> Regards from the Rocky Mountains -
> 
> Jack
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Jack Harper, President
> Secure Outcomes Inc
> 2942 Evergreen Parkway, Suite 300
> Evergreen, Colorado 80439 USA
> 
> 303.670.8375
> 303.670.3750 (fax)
> 
> http://www.secureoutcomes.net for Product Info. 


Re: Visicalc Addendum

2017-10-17 Thread Fred Cisin via cctalk
"Entry in my journal: First complete VisiCalc in a package was October 19, 
1979. I received a copy the next day as I recall."


http://www.bricklin.com/history/saiproduct1.htm

So, Murray gave us a few extra days to prepare for the party.


BTW, "conception of the idea" is what is commemorated at Harvard!
SHIPMENT is a more objective measure, but vaporware is a tradition.




Re: Visicalc

2017-10-17 Thread Fred Cisin via cctalk

On 17 October 2017 at 22:51, Murray McCullough via cctalk
 wrote:

Today marks the 36 anniversary of Visicalc a seminal program in the
world of classic computing.
Happy computing!
Murray  :)


On Wed, 18 Oct 2017, Liam Proven via cctalk wrote:

I just had a dig through Dan Bricklin's website.
There's no date I can see for first release or first shipping,
although it comments that the first version shipped to customers was
1.35.
So it's not Visicalc 1.0's release, and anyway, it was 1979, so it's
thirty _eight_ years ago, no?


"We first shipped about five copies of version 1.35 to some early 
customers in the late summer of 1979. I hand typed the labels. The first 
"real" release, version 1.37, shipped in mid-October 1979."

http://www.bricklin.com/history/saiproduct1.htm

Well, "anniversary"??
Of "idea"?1978
Of writing it? Spring 1979
Contracting marketing?  Spring 1979
Public demonstration AS A PRODUCT? May 1979
Advertising AS A PRODUCT? May 1979
"Official Launch"?  June 1979
1st shipment (5 copies w/ hand-typed labels of 1.35)? Late summer 1979
"Real" release (presumably large quantity)?  "Mid-October 1979."

if we go with "real' release,
then Murray merely typo'ed 36 years,
when it was correctly 38 years.

(I KNEW that I had dealt with it in 1980!)

I'd say, that WITH that correction, Murray's post is defensibly correct!

Although MOST companies count their voporware times,
and count from the first idea,
or from completion of code of the the first [not necessarily released!] 
prototype version,

or at least ALWAYS from the first public demonstration and "launch",
rather than when it actually shows up on store shelves!

THAT distinction is essential with all "FIRST"s,
such as Apple V TRS80 V PET


BTW, at Vista College, in 1982?,  one of our lab techs patched it, and 
Scripsit, for use with TRS232 printer interface, and for Exatron Stringy 
Floppy.


OB_Irrelevant:
In 2006, Vista College moved to a new building, and simultaneously changed 
its name to "Berkeley City College".  I, and a few others, argued that the 
move and name change should NEVER be at the same time, or you lose ALL 
presence, and it effectively becomes closing one business and opening 
another!  ALSO, a few of us argued that the old name should remain in 
parallel.  Not only just for the necessary continuity, but ALSO, since a 
lot of our Computer Information Systems classes were remedial job 
training for the digital sweatshop, we had courses on using the OS (in 
addition to MY course that dealt with OS internals).  Since Microsoft was 
in the midst of releasing Windows VISTA, we could have had great simple 
advertising of

"Vista College - the best place to learn Windows Vista!"

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


Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread dwight via cctalk
Since you know the pinout of the SIO chip, you might first look to see if where 
the rx and tx pins go. This may require some hunting with an ohm meter. I'd 
suspect they go to a RS232 level shifter.

You may also have to write some code to run the serial chip and any possible 
external loopback. As I recall these chips may have an internal loopback.

If you have a working logic analyzer, you can trigger on the select pin to the 
SIO and look to see what address the SIO is located at. That will allow you to 
create some debug code.

I'm not saying this is easy. Still, this is the way I'd attack the problem as a 
start.

You have to realize, there is not much more we can do for you.

Creating a ROM with a diagnostic looping program is about the only practical 
way to deal with a machine with no documentation.

I fixed an old mini once without schematics but it was all DTL and TTL and 
there were signal names at the card edges.

You have a Z80 computer. If you can program EPROMs you have a chance, otherwise 
it is unlikely that your current easter egg hunting method is likely to be very 
fruitful. You have already gone through most all of the likely failure items. 
From here you will likely have to begin to troubleshoot.

Dwight



From: cctalk  on behalf of Dominique Carlier via 
cctalk 
Sent: Tuesday, October 17, 2017 1:59:47 PM
To: Chuck Guzis; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette 
subsystem : Restoration

Thanks for your response Chuck,

As described in the topic, just after the Power On, the machine runs a
self-test which is called "POC TEST" on the UTS range of Sperry Univac.
During this test, the machine checks the status of the RAM, the ROMs,
the Counter Timer, and the various communication interfaces.
Everything is OK except the ninth line which says: "SERIAL I / O CHANNEL
B: FAILED"

(ignore the FAILED next to "OPTIONAL RAM BANK 0,1", the machine can
start without this board)
http://www.zeltrax.com/classiccmp_forum/uts40_screen03.jpg

This channel B error completely freezes the machine, it does not load
the default settings, I no longer have access to the setup page, in this
situation the keyboard remains without effects.

When the POC test is successful, it loads the default settings in non
volatile RAM:
http://www.zeltrax.com/classiccmp_forum/uts40_screen01.jpg

And I can access the setup page:
http://www.zeltrax.com/classiccmp_forum/uts40_screen02.jpg

The few times I was able to go into the setup page (CHANNEL B: PASSED),
I rushed to try to encode (with the dead keyboard) the data to declare
the subsystem and finally return to the CP/M mode. And I had twice the
case where without warning hop! Blank screen, automatic reset, self-test
(POC) -> SERIAL I / O CHANNEL B: FAILED (again).
Maybe we have there some interesting information about the problem, the
intermittent nature of this failure, could this give information about
the type of component in fault?

But note that since weeks now the problem has become permanent, I have
never been able to return to this famous setup page and the "serial I/O
channel B" is now always marked as 'FAILED'.

So I have no way to try anything using the terminal at this point.

It is possible that the breakdown is in fact very simple (dry solder dry
or attacked solder by the acid of the battery), but I would like to
avoiding to rework all the solders, and maybe to finally find that the
problem was at the level of an IC, I would try to locate the components
linked to this problem. I look at the SIO, try to discover what is after
just after, see how I can eventually act on the pin 30 (W/RDYB) of that IC :
http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg


And try to understand why this SIO no longer considers the channel B as
'READY'
This kind of things ...
There are probably programmable loop-back circuitry used by the POC test
program (in the ROM of the program cartridge).To ignore the negative
diagnostic I would like to induce to the self-test program that the
channel B is OK, what should I inject to the SIO (perhaps on this pin
30) to force a positive diagnosis?
It would be interesting, just to see if in that way I can take control
again on the machine, and check that the rest is working.

And yes, the SIO is working (as the CPU, the counter timer and the DMA
controller) because I replaced these IC by another ones with the same
faulty result.
http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg

Thanks for your help ;-)

Dominique


On 17/10/2017 20:22, Chuck Guzis via cctalk wrote:
> On 10/17/2017 10:50 AM, Dominique Carlier via cctalk wrote:
>> Hi Chuck,
>>
>> Yes I understand well. But the fact that the machines Z80 based were all
>> equipped with this famous serial I/O channel A and B, I therefore
>> thought that the principle of verification of these channels would
>> 

Re: Visicalc

2017-10-17 Thread Fred Cisin via cctalk

On Tue, 17 Oct 2017, Murray McCullough via cctalk wrote:

Today marks the 36 anniversary of Visicalc a seminal program in the
world of classic computing.
Happy computing!
Murray  :)


36 years is not accurate.  Nor is "today".
38 and a half years.

http://www.bricklin.com/history/sai.htm

Visicalc was advertised in May 1979 Byte,

and demonstrated in May 1979 by Dan Bricklin at the West Coast Computer 
Faire (which was also the first one that I exhibited at)


It had an "official launch" in June 1979 at NCC (National Computer 
Conference)

The first version ran on Apple II.

Dan Bricklin and Bob Frankston formed "Software Arts" (January 1979), but 
handed over marketing of Visicalc to "Personal Software" (Dan Fylstra, 
Peter Jennings).


In the early days of microcomputer software, there were few precedents for 
royalty amounts, and the royalties were sometimes reported to be 37%!

(later, more typically 8 - 12%)

Personal Software felt the pinch from those royalty amounts, and started 
to negotiate to lower the royalties, buy the program outright from 
Software Arts, or merge the companies.


Imitations soon developed, including SuperCalc (1980) and MultiPlan 
(1981).

The imitations became known in the trade as "VisiCLONES"

Personal Software however tried to cash in on the name, by coming out with 
Visi- programs.  "from the same people who brought you VisiCalc".


A port to TRS-80 came soon.
When IBM was developing the PC, they were not stupid enough to ignore the 
need for software, so they contracted for a version of VisiCalc to be 
released along with the PC on August 11, 1981.
For various reasons, they did NOT go with Wordstar (the obvious choice for 
a word processor), and contracted for Easy Writer (written by John 
"Captain Crunch" Draper).  If IBM were to have known that it was by 
Draper, then they would surely have tried harder to negotiate with 
MicroPro (Later renamed "Wordstar International") for WordStar!


Less than half a year later, Personal Software renamed themselves 
"VisiCorp".  It helps a LOT to have the company and the primary program 
sharing a name!  (That's why I renamed "Berkeley Microcomputer" into 
"XenoSoft")


Mitch Kapor formed Lotus Development Corp in 1983.  1-2-3 was written 
originally by Jonathan Sachs.  Lotus 1-2-3 was released in January 1983, 
and immediately sold better than VisiCalc.  It became the most successful 
of the VisiClones, and dominated the market for years, before eventually 
being replaced by MicroSoft Excel.


In 1983, VisiCorp, after being unsuccessful in negotiating lower 
royalties, purchase, or merger, sued Software Arts, claiming late 
delivery.  Besides millions of dollars, they wanted to be exempt from 
royalties for the version of VisiCalc in VisiON.
In 1984, Software Arts counter sued for "breach of contract".  In mid 
1984, a settlement was reached - VisiCorp payed Software Arts an 
undisclosed amount of money.  Software Arts got the VisiCalc trademark, 
but VisiCorp got "Visi-" as a prefix for other programs.


Software Arts went under, selling its assets to Lotus, and Bricklin and 
Frankston working for Lotus for a while.


Visicorp was bought by Paladin Software in November 1984.

Eventually, Paladin Software went under.


Adam Osborne, after the fall of Osborne Computer, formed "Paperback 
Software" to market very cheap knockoffs of popular software, including a 
VisiClone named "VP-Planner".   Up to that point, it was generally 
accepted that the code in software was copyrightable, but not the overall 
idea, permitting lots of imitations of PuckMan (later "PacMan" to avoid 
vandalism of the arcade machines)


Lotus saw it differently, and sued paperback software out of existence 
because VP-Planner looked and behaved just like their own VisiClone.

That was the start of "look and feel"["and smell"] IP,

Jerry Pournelle and I came up with the idea that if Adam were to buy the 
residue of Paladin for a few tens of thousands of dollars, which included 
the residue of VisiCorp, which had rights to be able to use the VisiCalc 
user interface (Software Arts did not claim ownership of VisOn VisiCalc), 
then he would be protected!  But, he took too long, and 
missed out.(neither Jerry nor Adam are still around)
(cf. the Jefferson Airplane album cover of "Thirty Seconds Over 
Winterland", which would have blown away the BerkeleySystems V Delrina 
lawsuit;
cf. Novell's purchase of of the IP rights of DRI (CP/M) provided 
significant legal leverage if the legal situation with MicroSoft heated 
up)



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


Re: Visicalc

2017-10-17 Thread Liam Proven via cctalk
On 17 October 2017 at 22:51, Murray McCullough via cctalk
 wrote:
> Today marks the 36 anniversary of Visicalc a seminal program in the
> world of classic computing.
>
> Happy computing!
>
> Murray  :)

I just had a dig through Dan Bricklin's website.

There's no date I can see for first release or first shipping,
although it comments that the first version shipped to customers was
1.35.

So it's not Visicalc 1.0's release, and anyway, it was 1979, so it's
thirty _eight_ years ago, no?

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Talk/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053


Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Dominique Carlier via cctalk

Thanks for your response Chuck,

As described in the topic, just after the Power On, the machine runs a 
self-test which is called "POC TEST" on the UTS range of Sperry Univac.
During this test, the machine checks the status of the RAM, the ROMs, 
the Counter Timer, and the various communication interfaces.
Everything is OK except the ninth line which says: "SERIAL I / O CHANNEL 
B: FAILED"


(ignore the FAILED next to "OPTIONAL RAM BANK 0,1", the machine can 
start without this board)

http://www.zeltrax.com/classiccmp_forum/uts40_screen03.jpg

This channel B error completely freezes the machine, it does not load 
the default settings, I no longer have access to the setup page, in this 
situation the keyboard remains without effects.


When the POC test is successful, it loads the default settings in non 
volatile RAM:

http://www.zeltrax.com/classiccmp_forum/uts40_screen01.jpg

And I can access the setup page:
http://www.zeltrax.com/classiccmp_forum/uts40_screen02.jpg

The few times I was able to go into the setup page (CHANNEL B: PASSED), 
I rushed to try to encode (with the dead keyboard) the data to declare 
the subsystem and finally return to the CP/M mode. And I had twice the 
case where without warning hop! Blank screen, automatic reset, self-test 
(POC) -> SERIAL I / O CHANNEL B: FAILED (again).
Maybe we have there some interesting information about the problem, the 
intermittent nature of this failure, could this give information about 
the type of component in fault?


But note that since weeks now the problem has become permanent, I have 
never been able to return to this famous setup page and the "serial I/O 
channel B" is now always marked as 'FAILED'.


So I have no way to try anything using the terminal at this point.

It is possible that the breakdown is in fact very simple (dry solder dry 
or attacked solder by the acid of the battery), but I would like to 
avoiding to rework all the solders, and maybe to finally find that the 
problem was at the level of an IC, I would try to locate the components 
linked to this problem. I look at the SIO, try to discover what is after 
just after, see how I can eventually act on the pin 30 (W/RDYB) of that IC :

http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg


And try to understand why this SIO no longer considers the channel B as 
'READY'

This kind of things ...
There are probably programmable loop-back circuitry used by the POC test 
program (in the ROM of the program cartridge).To ignore the negative 
diagnostic I would like to induce to the self-test program that the 
channel B is OK, what should I inject to the SIO (perhaps on this pin 
30) to force a positive diagnosis?
It would be interesting, just to see if in that way I can take control 
again on the machine, and check that the rest is working.


And yes, the SIO is working (as the CPU, the counter timer and the DMA 
controller) because I replaced these IC by another ones with the same 
faulty result.

http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg

Thanks for your help ;-)

Dominique


On 17/10/2017 20:22, Chuck Guzis via cctalk wrote:

On 10/17/2017 10:50 AM, Dominique Carlier via cctalk wrote:

Hi Chuck,

Yes I understand well. But the fact that the machines Z80 based were all
equipped with this famous serial I/O channel A and B, I therefore
thought that the principle of verification of these channels would
probably be the same on this type of architecture (Z80+PIO+CTC+SIO).
Therefore, there should be probably more people able to give me some
useful information.

Perhaps, but we don't know exactly what surrounds the Z80 SIO, or
exactly what the diagnostic is complaining about.   Does your SIO have
anything other than line drivers or receivers on its external interface?
  Some systems have programmable loop-back circuitry to enable the
terminal to function to talk to itself and verify functionality.

If you ignore the diagnostic message and feed the terminal some serial
data, do the inputs on the SIO wiggle appropriately in response?  In
other words, is the data getting from the connector to the SIO chip?

Troubleshooting is slow, methodical work.

The SIO/DART chip itself is very simple--and most likely not the cause
of the diagnostic failure.  But writing your own diagnostic software can
verify that.

At least that's what I think from a few thousand km away.

--Chuck






Visicalc

2017-10-17 Thread Murray McCullough via cctalk
Today marks the 36 anniversary of Visicalc a seminal program in the
world of classic computing.

Happy computing!

Murray  :)


Re: Anyone in Canada (preferably BC) running RSX?

2017-10-17 Thread Brent Hilpert via cctalk
I don't have the stuff to do the disk recovery, but two years ago I got a 
telidon image decoder/display working (the original hardware) at request of 
someone who had images/data to display.

He had already done a lot of work recovering data and (IIRC) had a software 
decoder for later-protocol images.

There are a couple of versions of the protocol, the hardware display/decoder I 
had dealt with an earlier version of the protocol.

The software decoder presented the images on a modern computer, I don't know if 
it converted them to a modern graphics file format.

Between he and I, we can perhaps help with the telidon image display end.



On 2017-Oct-17, at 1:00 PM, Chuck Guzis via cctalk wrote:

> I've just received a query from an outfit in BC who has a few (<10) RSX
> (apparently) either RX01 or RX02 floppies that they'd like to extract
> the files from.
> 
> Since the number of floppies is small and it's an international affair,
> I'd rather not do the work myself.
> 
> Bonus points if you can translate Telidon images to modern graphics.
> 
> Drop me a private email if you're up for the work.
> 
> --Chuck



Anyone in Canada (preferably BC) running RSX?

2017-10-17 Thread Chuck Guzis via cctalk
I've just received a query from an outfit in BC who has a few (<10) RSX
(apparently) either RX01 or RX02 floppies that they'd like to extract
the files from.

Since the number of floppies is small and it's an international affair,
I'd rather not do the work myself.

Bonus points if you can translate Telidon images to modern graphics.

Drop me a private email if you're up for the work.

--Chuck


Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread dwight via cctalk

You can not fix anything without knowing what it is suppose to do. Chuck's idea 
is sound. You will not likely get much with the logic analyzer unless the 
processor is actually running some code.

It doesn't sound like it is. You need to check that it is.

Dwight




From: cctalk  on behalf of Dominique Carlier via 
cctalk 
Sent: Tuesday, October 17, 2017 10:50:29 AM
To: Chuck Guzis via cctalk
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette 
subsystem : Restoration

Hi Chuck,

Yes I understand well. But the fact that the machines Z80 based were all
equipped with this famous serial I/O channel A and B, I therefore
thought that the principle of verification of these channels would
probably be the same on this type of architecture (Z80+PIO+CTC+SIO).
Therefore, there should be probably more people able to give me some
useful information.

Dominique


On 17/10/2017 19:26, Chuck Guzis via cctalk wrote:
> On 10/17/2017 04:56 AM, Dominique Carlier via cctalk wrote:
>> Hi guys!
>>
>> Nobody here has any information to help me to solve my problem?
>> Do you think I should talk about this breakdown on another forum? If
>> yes, have you an address to recommend me?
>>
> Dominique, the probably reason that many of us don't jump in is that
> you've got a tough job, given the house-numbered ICs and lack of visible
> traces.
>
> If this were my system and I was determined to get it working, I'd
> probably start by dumping and disassembling the ROMs to find out exactly
> what set of program steps occur to produce the error message.
>
> I'd probably then write a diagnostic ROM that would allow me to probe in
> detail to characterize the fault.  The happy circumstance is that the
> display (and possibly the keyboard) is functional.)
>
> Then I'd jump in with a logic analyzer or ICE to determine the exact
> nature of the failure and its source.
>
> You can see that this is an arduous process that few are equipped to
> help you diagnose remotely.
>
> My two cents' worth,
> Chuck
>
>



Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Chuck Guzis via cctalk
On 10/17/2017 10:50 AM, Dominique Carlier via cctalk wrote:
> Hi Chuck,
> 
> Yes I understand well. But the fact that the machines Z80 based were all
> equipped with this famous serial I/O channel A and B, I therefore
> thought that the principle of verification of these channels would
> probably be the same on this type of architecture (Z80+PIO+CTC+SIO).
> Therefore, there should be probably more people able to give me some
> useful information.

Perhaps, but we don't know exactly what surrounds the Z80 SIO, or
exactly what the diagnostic is complaining about.   Does your SIO have
anything other than line drivers or receivers on its external interface?
 Some systems have programmable loop-back circuitry to enable the
terminal to function to talk to itself and verify functionality.

If you ignore the diagnostic message and feed the terminal some serial
data, do the inputs on the SIO wiggle appropriately in response?  In
other words, is the data getting from the connector to the SIO chip?

Troubleshooting is slow, methodical work.

The SIO/DART chip itself is very simple--and most likely not the cause
of the diagnostic failure.  But writing your own diagnostic software can
verify that.

At least that's what I think from a few thousand km away.

--Chuck



Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Dominique Carlier via cctalk

Hi Chuck,

Yes I understand well. But the fact that the machines Z80 based were all 
equipped with this famous serial I/O channel A and B, I therefore 
thought that the principle of verification of these channels would 
probably be the same on this type of architecture (Z80+PIO+CTC+SIO). 
Therefore, there should be probably more people able to give me some 
useful information.


Dominique


On 17/10/2017 19:26, Chuck Guzis via cctalk wrote:

On 10/17/2017 04:56 AM, Dominique Carlier via cctalk wrote:

Hi guys!

Nobody here has any information to help me to solve my problem?
Do you think I should talk about this breakdown on another forum? If
yes, have you an address to recommend me?


Dominique, the probably reason that many of us don't jump in is that
you've got a tough job, given the house-numbered ICs and lack of visible
traces.

If this were my system and I was determined to get it working, I'd
probably start by dumping and disassembling the ROMs to find out exactly
what set of program steps occur to produce the error message.

I'd probably then write a diagnostic ROM that would allow me to probe in
detail to characterize the fault.  The happy circumstance is that the
display (and possibly the keyboard) is functional.)

Then I'd jump in with a logic analyzer or ICE to determine the exact
nature of the failure and its source.

You can see that this is an arduous process that few are equipped to
help you diagnose remotely.

My two cents' worth,
Chuck






Re: OT: the death of shortwave / Re: Hallicrafters S-85

2017-10-17 Thread Diane Bruce via cctalk
On Tue, Oct 17, 2017 at 09:32:38AM -0500, Jay West via cctalk wrote:
> Us lowly technician license holders would love to participate :)

Hey there is always DMR or something. de VA3DB
> 
> J/KE0FJW
> 
> 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db


Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Dominique Carlier via cctalk

Hi Mattis !

I'm afraid I do not have the required skills :-/

I have never used this kind of tools. However I recovered this recently:
http://actingmachines.com/img/photos/package/europacorp/tektronix_1240_b.jpg 



But in the present state of my knowledge, I could not use it. Is it 
difficult for a novice to learn how to use it?


If I could just know what is the principle of the verification system of 
the PIO's channels A & B, and also what are the integrated circuits 
concerned? That would be valuable information.


Dominique

On 17/10/2017 17:09, Mattis Lind wrote:



2017-10-17 13:56 GMT+02:00 Dominique Carlier via cctalk 
>:


Hi guys!

Nobody here has any information to help me to solve my problem?
Do you think I should talk about this breakdown on another forum?
If yes, have you an address to recommend me?

Thanks

Dominique



I don't know anything about the system you are about to repair but it 
make use of a standard CPU which is kind of useful when the schematic 
is missing. If I were you I would attach my trusty logic analyzer over 
the CPU to try to trace what it is doing. Which ROM does it access 
when it is doing the power up self test? Use a disassmbler on that 
particular ROM and work out what flow the CPU takes in the ROM 
contents and try to understand what causes it to take the decision 
that something is broken.


Since my logic analyzer has fairly limited memory depth I would have 
it to trigger on for example accessing the SIO.


/Mattis




On 15/10/2017 23:12, Dominique Carlier via cctalk wrote:

Hi everybody,

As I have no documentation / schematics I started to look for
computer schematics where it is about Z80 and “serial I/O
channel B”, I found a lot of data about this subject that I do
not know at all.
These information would allow me to better target the
breakdown, if any of you would consent to pass on some of his
knowledge.
In all documentation on Z80 based machines, I find the same
elements, similar architectures: CPU, PIO, CTC, SIO.

http://www.z80.info/gfx/nascom1main.gif

http://www.ep128.hu/Sp_Konyv/Pic/SIO_11.gif


I interchanged with the IC of my other CPU board which are of
the same model.
http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg


But the error persists, so the problem is around.
I'm trying to find out why the SIO detects a problem on the
channel B. How does this detection system work? What are the
solicited ICs? Do they communicate through other ICs like
multiplexers or others?

I would also like to simulate the absence of this problem in
order to see if this allows my UTS to have a successful POC
test, to have again access to the setup page of the machine.
Is it possible to do something at the SIO pin 30 (W/RDYB) to
pretend that the B channel is OK?
http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg


Can we imagine that the problem would be at the level of what
checks channel B and not channel B itself?
I also read a lot of obscure thing about memory, and I still
wonder if a memory problem could also play a part in this
failure? You must understand that I continue to try to
troubleshoot this machine like the others, comparative logic
without advanced academic knowledge, a challenge every time.

It's even harder because I have trouble identifying the
components. I do not find any results concerning the 3/4 of
the ICs, as for example these:
http://www.zeltrax.com/classiccmp_forum/sio_issue_02.jpg


And even for components like this, "AVX 224Z 8238"
http://www.zeltrax.com/classiccmp_forum/sio_issue_03.jpg


(ceramic capacitor of 220nf 50v? not sure)

There is also the fact that the tracks are not visible on the
CPU board which I try to repair, so I try to locate myself by
comparing component location to the original CPU board, in
short a beautiful mess.
Meanwhile, I restore this beautiful Key Tronics keyboard which
was in a very sad condition. Here are some pictures of this
restoration (work in progress)

http://www.zeltrax.com/classiccmp_forum/keyboard2_01.jpg


http://www.zeltrax.com/classiccmp_forum/keyboard2_02.jpg

Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Chuck Guzis via cctalk
On 10/17/2017 04:56 AM, Dominique Carlier via cctalk wrote:
> Hi guys!
> 
> Nobody here has any information to help me to solve my problem?
> Do you think I should talk about this breakdown on another forum? If
> yes, have you an address to recommend me?
> 

Dominique, the probably reason that many of us don't jump in is that
you've got a tough job, given the house-numbered ICs and lack of visible
traces.

If this were my system and I was determined to get it working, I'd
probably start by dumping and disassembling the ROMs to find out exactly
what set of program steps occur to produce the error message.

I'd probably then write a diagnostic ROM that would allow me to probe in
detail to characterize the fault.  The happy circumstance is that the
display (and possibly the keyboard) is functional.)

Then I'd jump in with a logic analyzer or ICE to determine the exact
nature of the failure and its source.

You can see that this is an arduous process that few are equipped to
help you diagnose remotely.

My two cents' worth,
Chuck



Re: Halt and Catch Fire (TV series)

2017-10-17 Thread Geoffrey Oltmans via cctalk
I felt like Cardiff also had a resemblance to Tandy/Radio Shack as well,
since they were in the electronics business before getting into computers.

On Sun, Oct 15, 2017 at 3:24 PM, tom sparks via cctalk <
cctalk@classiccmp.org> wrote:

> I have just finished watching [Halt and Catch Fire](
> https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(TV_series))
> I've tried to Identify the companies the show represents
>
> early 1980-1985 (Season 1):
>
> * Cardiff Electric = [Compaq](https://en.wikipedia.org/wiki/Compaq)
> Joe MacMillan, Gordon Clark, Cameron Howe
>
> 1985-1989 (Season 2-3):
>
> * Muntiy = [PlayNET](https://en.wikipedia.org/wiki/PlayNET) / [Quantum
> Link](https://en.wikipedia.org/wiki/Quantum_Link) / [Habitat](
> https://en.wikipedia.org/wiki/Habitat_(video_game))
>  Cameron Howe ( founder ), Donna Clark
> * MacMillan = [McAfee](https://en.wikipedia.org/wiki/McAfee)
> Joe MacMillan ( founder )
> *  Unknown? = [NSFNET Regional networks](https://en.wikipedia
> .org/wiki/National_Science_Foundation_Network#Regional_networks)
> Joe MacMillan ( founder )
> * Gordon Clark computers = [Dell](https://en.wikipedia.or
> g/wiki/History_of_Dell)
> Gordon Clark ( founder )
>
> 1990 -1995 (Season 4):
>
> * Comet = [Yahoo! Directory?](https://en.wikiped
> ia.org/wiki/Yahoo!_Directory)
> Gordon Clark ( founder ), Joe MacMillan
> * Rover = [AltaVista?](https://en.wikipedia.org/wiki/AltaVista)
> Donna Clark ( intervestor )
>
>
> Issues I had was:
>
> * Hollywood hacking: [packet sniffer](https://en.wikipedia.
> org/wiki/Packet_analyzer) = bloodhound
> * Amiga computer: poor portrayal, looked like a DOS  computer
>
>


Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Mattis Lind via cctalk
2017-10-17 13:56 GMT+02:00 Dominique Carlier via cctalk <
cctalk@classiccmp.org>:

> Hi guys!
>
> Nobody here has any information to help me to solve my problem?
> Do you think I should talk about this breakdown on another forum? If yes,
> have you an address to recommend me?
>
> Thanks
>
> Dominique



I don't know anything about the system you are about to repair but it make
use of a standard CPU which is kind of useful when the schematic is
missing. If I were you I would attach my trusty logic analyzer over the CPU
to try to trace what it is doing. Which ROM does it access when it is doing
the power up self test? Use a disassmbler on that particular ROM and work
out what flow the CPU takes in the ROM contents and try to understand what
causes it to take the decision that something is broken.

Since my logic analyzer has fairly limited memory depth I would have it to
trigger on for example accessing the SIO.

/Mattis

>
>
>
> On 15/10/2017 23:12, Dominique Carlier via cctalk wrote:
>
>> Hi everybody,
>>
>> As I have no documentation / schematics I started to look for computer
>> schematics where it is about Z80 and “serial I/O channel B”, I found a lot
>> of data about this subject that I do not know at all.
>> These information would allow me to better target the breakdown, if any
>> of you would consent to pass on some of his knowledge.
>> In all documentation on Z80 based machines, I find the same elements,
>> similar architectures: CPU, PIO, CTC, SIO.
>>
>> http://www.z80.info/gfx/nascom1main.gif
>> http://www.ep128.hu/Sp_Konyv/Pic/SIO_11.gif
>>
>> I interchanged with the IC of my other CPU board which are of the same
>> model.
>> http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg
>>
>> But the error persists, so the problem is around.
>> I'm trying to find out why the SIO detects a problem on the channel B.
>> How does this detection system work? What are the solicited ICs? Do they
>> communicate through other ICs like multiplexers or others?
>>
>> I would also like to simulate the absence of this problem in order to see
>> if this allows my UTS to have a successful POC test, to have again access
>> to the setup page of the machine.
>> Is it possible to do something at the SIO pin 30 (W/RDYB) to pretend that
>> the B channel is OK?
>> http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg
>>
>> Can we imagine that the problem would be at the level of what checks
>> channel B and not channel B itself?
>> I also read a lot of obscure thing about memory, and I still wonder if a
>> memory problem could also play a part in this failure? You must understand
>> that I continue to try to troubleshoot this machine like the others,
>> comparative logic without advanced academic knowledge, a challenge every
>> time.
>>
>> It's even harder because I have trouble identifying the components. I do
>> not find any results concerning the 3/4 of the ICs, as for example these:
>> http://www.zeltrax.com/classiccmp_forum/sio_issue_02.jpg
>>
>> And even for components like this, "AVX 224Z 8238"
>> http://www.zeltrax.com/classiccmp_forum/sio_issue_03.jpg
>>
>> (ceramic capacitor of 220nf 50v? not sure)
>>
>> There is also the fact that the tracks are not visible on the CPU board
>> which I try to repair, so I try to locate myself by comparing component
>> location to the original CPU board, in short a beautiful mess.
>> Meanwhile, I restore this beautiful Key Tronics keyboard which was in a
>> very sad condition. Here are some pictures of this restoration (work in
>> progress)
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_01.jpg
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_02.jpg
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_03.jpg
>> 
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_04.jpg
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_05.jpg <
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_05.jpg>
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_06.jpg <
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_06.jpg>
>>
>> http://www.zeltrax.com/classiccmp_forum/keyboard2_07.jpg
>>
>> In any case I hold on, restarting this machine has become an obsession,
>> but without help I will still be on it for the next 10 years, thus  HELP!
>> ;-)
>>
>>
>> Everything would be perfectly fine if most of the time I did not have at
>>> startup an error at line 9. of the POC test:
>>>

> SERIAL I / O CHANNEL B: FAILED
>


>>
>>
>


RE: OT: the death of shortwave / Re: Hallicrafters S-85

2017-10-17 Thread Jay West via cctalk
Us lowly technician license holders would love to participate :)

J/KE0FJW





Re: OT: the death of shortwave / Re: Hallicrafters S-85

2017-10-17 Thread allison via cctalk


Conditions have been poor for HF lately but some of the higher bands 
like 15,10 and 6
have seen Es and extended propagation despite the current point in the 
sunspot cycle.


Nets I listen to and sometimes check into...

7.163 5-7am east coast time, wb2rem NC.  informal ssb DX net with chat.
  I am mobile during this window.
1945kcs Grey Hair net, AM mode,  8pm eastern.
Afternoon I put up 14.300 on the mobile for the Marine maritime net.
50.272 SSB, Sundays 9:30 AM local (east cost) NC me and two others.

No band scared or left unused 160M through 432MHZ.

Allison/kb1gmx



On 10/17/17 7:17 AM, Bill Gunshannon via cctalk wrote:

And to keep it in the classic vein it should be done on AM.  


bill - KB3YV


From: cctalk  on behalf of sandy hamlet via cctalk 

Sent: Monday, October 16, 2017 8:53 PM
To: Ben Sinclair; General Discussion, On-Topic and Off-Topic Posts
Subject: Re: OT: the death of shortwave / Re: Hallicrafters S-85

Ben,

I'm on the west coast, California, and have antenna's for 40 and 80.
There are several nets on the west coast but none that talk classic computers.
Maybe we need one?
Informal would be the best.


- Original Message -
From: "General Discussion, On-Topic and Off-Topic Posts" 
To: "General Discussion, On-Topic and Off-Topic Posts" 
Sent: Monday, October 16, 2017 11:58:33 AM
Subject: Re: OT: the death of shortwave / Re: Hallicrafters S-85

On Mon, Oct 16, 2017 at 1:24 PM, Ian S. King via cctalk <
cctalk@classiccmp.org> wrote:


Does anyone on this thread know if there are any regularly scheduled
traffic nets?


I don't do much with HF nets, traffic or otherwise, but I would be
interested in participating in an informal classic computing net if we
could get one going! I'm mostly active on 20M and 40M.

--
Ben Sinclair
b...@bensinclair.com





Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette subsystem : Restoration

2017-10-17 Thread Dominique Carlier via cctalk

Hi guys!

Nobody here has any information to help me to solve my problem?
Do you think I should talk about this breakdown on another forum? If 
yes, have you an address to recommend me?


Thanks

Dominique


On 15/10/2017 23:12, Dominique Carlier via cctalk wrote:

Hi everybody,

As I have no documentation / schematics I started to look for computer 
schematics where it is about Z80 and “serial I/O channel B”, I found a 
lot of data about this subject that I do not know at all.
These information would allow me to better target the breakdown, if 
any of you would consent to pass on some of his knowledge.
In all documentation on Z80 based machines, I find the same elements, 
similar architectures: CPU, PIO, CTC, SIO.


http://www.z80.info/gfx/nascom1main.gif
http://www.ep128.hu/Sp_Konyv/Pic/SIO_11.gif

I interchanged with the IC of my other CPU board which are of the same 
model.

http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg

But the error persists, so the problem is around.
I'm trying to find out why the SIO detects a problem on the channel B. 
How does this detection system work? What are the solicited ICs? Do 
they communicate through other ICs like multiplexers or others?


I would also like to simulate the absence of this problem in order to 
see if this allows my UTS to have a successful POC test, to have again 
access to the setup page of the machine.
Is it possible to do something at the SIO pin 30 (W/RDYB) to pretend 
that the B channel is OK?

http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg

Can we imagine that the problem would be at the level of what checks 
channel B and not channel B itself?
I also read a lot of obscure thing about memory, and I still wonder if 
a memory problem could also play a part in this failure? You must 
understand that I continue to try to troubleshoot this machine like 
the others, comparative logic without advanced academic knowledge, a 
challenge every time.


It's even harder because I have trouble identifying the components. I 
do not find any results concerning the 3/4 of the ICs, as for example 
these:

http://www.zeltrax.com/classiccmp_forum/sio_issue_02.jpg

And even for components like this, "AVX 224Z 8238"
http://www.zeltrax.com/classiccmp_forum/sio_issue_03.jpg

(ceramic capacitor of 220nf 50v? not sure)

There is also the fact that the tracks are not visible on the CPU 
board which I try to repair, so I try to locate myself by comparing 
component location to the original CPU board, in short a beautiful mess.
Meanwhile, I restore this beautiful Key Tronics keyboard which was in 
a very sad condition. Here are some pictures of this restoration (work 
in progress)


http://www.zeltrax.com/classiccmp_forum/keyboard2_01.jpg

http://www.zeltrax.com/classiccmp_forum/keyboard2_02.jpg

http://www.zeltrax.com/classiccmp_forum/keyboard2_03.jpg

http://www.zeltrax.com/classiccmp_forum/keyboard2_04.jpg

http://www.zeltrax.com/classiccmp_forum/keyboard2_05.jpg 



http://www.zeltrax.com/classiccmp_forum/keyboard2_06.jpg 



http://www.zeltrax.com/classiccmp_forum/keyboard2_07.jpg

In any case I hold on, restarting this machine has become an 
obsession, but without help I will still be on it for the next 10 
years, thus  HELP! ;-)



Everything would be perfectly fine if most of the time I did not have 
at startup an error at line 9. of the POC test:


SERIAL I / O CHANNEL B: FAILED 









Re: OT: the death of shortwave / Re: Hallicrafters S-85

2017-10-17 Thread Bill Gunshannon via cctalk

And to keep it in the classic vein it should be done on AM.  


bill - KB3YV


From: cctalk  on behalf of sandy hamlet via 
cctalk 
Sent: Monday, October 16, 2017 8:53 PM
To: Ben Sinclair; General Discussion, On-Topic and Off-Topic Posts
Subject: Re: OT: the death of shortwave / Re: Hallicrafters S-85

Ben,

I'm on the west coast, California, and have antenna's for 40 and 80.
There are several nets on the west coast but none that talk classic computers.
Maybe we need one?
Informal would be the best.


- Original Message -
From: "General Discussion, On-Topic and Off-Topic Posts" 
To: "General Discussion, On-Topic and Off-Topic Posts" 
Sent: Monday, October 16, 2017 11:58:33 AM
Subject: Re: OT: the death of shortwave / Re: Hallicrafters S-85

On Mon, Oct 16, 2017 at 1:24 PM, Ian S. King via cctalk <
cctalk@classiccmp.org> wrote:

>
> Does anyone on this thread know if there are any regularly scheduled
> traffic nets?
>

I don't do much with HF nets, traffic or otherwise, but I would be
interested in participating in an informal classic computing net if we
could get one going! I'm mostly active on 20M and 40M.

--
Ben Sinclair
b...@bensinclair.com



Re: DECmate disks

2017-10-17 Thread william degnan via cctalk
Will do, thanks Paul

Bill Degnan
twitter: billdeg
vintagecomputer.net
On Oct 17, 2017 1:10 AM, "Paul Anderson via cctalk" 
wrote:

> I have a few DECMATE I's here. Call me when you get a chance Bill,
>
> On Mon, Oct 16, 2017 at 9:25 PM, Zane Healy via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > That’s pretty cool, I’ve never seen anything like that.  Is
> > ftp.update.uu.se still online?  It at least used to have an archive of
> > PDP-8 stuff, including the DECmate.  I’m not sure if it has what you
> need.
> > I can’t help, my DECmate’s are III’s.
> >
> > Zane
> >
> >
> >
> >
> >
> > > On Oct 16, 2017, at 6:42 PM, william degnan via cctech <
> > cct...@classiccmp.org> wrote:
> > >
> > > Anyone have spare OS/8 for DECmate disks, RX02?   (copies originals
> does
> > > not matter).
> > >
> > > I have a lot of RX01 disks, not sure if I have any RX02's, but I'd
> offer
> > to
> > > trade what I can or pay a fair price.  I may need a VT278 to the
> pedestal
> > > drive cable.  I have a candidate cable that may work, but it's hacked
> up
> > > (split) and may not from a DECmate, just found in in the DEC cable bin.
> > > Not sure how rare the disks and/or cable are.  I also need a CPU card
> RAM
> > > module if anyone has one.  The VT278 appears to work ok without the
> last
> > > RAM pod/module in the back of the CPU card, but eventually I'll
> probably
> > > want a full 32K.  It may be required for DECmate OS/8.
> > >
> > > I realize It may be possible to make disks, working on that.  I know
> that
> > > RX02 is a format difficult to reproduce without effort, so I assume the
> > > shortest path is to find someone with a working DECmate, RX02 disks,
> and
> > > willingness to make a copy using the native system.  I would be happy
> to
> > > pay a fair price or trade stuff.   I don't have a RX02 drive controller
> > > card other than the DECmate CPU card, otherwise I'd make the disks
> > myself.
> > > I may be able to make a disk using imagedisk, looking into that, but I
> > have
> > > read that this is not easy.  I have more to research on the subject.
> > >
> > > Here are some photos of the DECmate I am working on.
> > > http://vintagecomputer.net/browse_thread.cfm?id=699
> > >
> > > Bill
> >
> >
>