Re: ID some core memory

[Adrian Stoness via cctalk]

would sperry univac fit those markings?

On Tue, Jan 2, 2018 at 6:09 PM, william degnan via cctalk <
cctalk@classiccmp.org> wrote:

> >
> >
> > >
> > >> Bill said
> > >>> Just curious...can anyone id the system that used these two types of
> > core
> > >>> memory?  I am thinking the first is a hand-made custom core, but the
> > 2nd
> > >> is
> > >>> definitely from a commercial system.  Looks kind of IBM-ish but it's
> > >>> nothing I can ID.  It's not an IBM 1401 I don't think.
> > >>> http://vintagecomputer.net/core-memory/
> > >>> Thanks
> > >>> Bill
> > >>
> > >> It's not a 1401 core plane. Here are a couple of pictures of what (I
> am
> > >> pretty sure) is a 1401 core plane that I have from my dad:
> > >>http://web.aanet.com.au/~malikoff/ibm/IBM_1401_core_memory_
> > plane_1.jpg
> > >> Close-up. Has a sharp molded corner and the grooves for the wires:
> > >>http://web.aanet.com.au/~malikoff/ibm/IBM_1401_core_memory_
> > plane_2.jpg
> > >>
> > >> Refer to PDF page 12 of http://www.bitsavers.org/pdf/
> > >> ibm/1401/A24-1403-5_1401_Reference_Apr62.pdf
> > >> for another photo of this.
> > >>
> > >> Steve.
> > >>
> > >>
> >
>
>
> I think given the IBM-esque printed markings all types of IBM core should
> be ruled out first.  For example the IBM 1620.  But now you can see why I
> am asking, what I have does not quite fit.
>
> On the wirewrap side there are four numbered grids on 4 physical plates,
> wired together.The ...'s represent "the continuation of wirewrap rows"
> 1,2,3,4,5,...33 etc.
>
> 1  [wirewrap] ---133 [wirewrap]  67 1
>    ..
> 33 165   99 32
>33
>
>
> 34
> 34 [wirewrap] ---   166  [wirewrap]  100  35
> .. ...  ... ...
> ... 66
> 66 198132
>

New DEC and other items for sale from Sellam's collection

[Sellam Ismail via cctalk]

Hello Folks, a most glorious and blessed new year to you all.

I have created a new DEC sales thread on the VCFed forums and populated it
with a batch of newly listed DEC cards:

http://www.vcfed.org/forum/showthread.php?61371-Sellam-s-DEC-Hardware-Software-and-Peripherals-Sales-Thread

I've also reduced the price of this nice PDP 11/03 basic system to $140:

http://www.vcfed.org/forum/showthread.php?57667-LLNL-LSI-11-Homebrew-system=llnl

I've also listed a few more items, an APL and standard bare keyboard, and a
homebrew front panel board:

http://www.vcfed.org/forum/showthread.php?58709-New-Items-For-Sale-Check-the-List-and-Make-an-Offer-or-Request=492319#post492319

As a reminder, I also started a S-100 thread for S-100 related sales:

http://www.vcfed.org/forum/showthread.php?61192-Sellam-s-S-100-Hardware-Software-and-Peripherals-Sales-Thread

Inquiries directly to me via e-mail get the fastest response.

Thanks!

Sellam

DEC H960 stabiliser feet. Have some questions.

[Steve Malikoff via cctalk]

I'm in need of some feet for my H960s and am intending to make a few pairs, so 
I thought I might
as well try and make them look close to the originals.
I have a few ideas on construction, for instance 3mm steel plate laser-cut and 
folded jigsaw fashion
then welded, or even simpler a basic welded steel bar with a 3D printed leg cap 
for asthetics.

I've been unsucessful in finding any closeup photos or drawings of these things 
so have used a diagram
from one of the 11/70 manuals which is the best I have so far. Thankfully they 
drew it in isometric so
it was easly to overdraw in CAD and project it to this:

http://web.aanet.com.au/~malikoff/pdp11/DEC_H960_stabiliser_foot_left_A-H952-BA.jpg

I have some questions-
Does the (optional?) sheetmetal kickplate play any role in securing these legs 
to the frame?
Are the two front screws are only there to hold them on and there is some 
internal box section that goes
into the front of the channel on the rack to take the weight?
Is the outer side tapered? It looks straight.
If the foot a one piece casting (presumably) or fabricated in some way?
Is the foot pad thread in the centre of the front of the leg, and is it the 
same thread and pad as the H960?

Finally I would really appreciate if someone could run a digital caliper over 
one, and fill in my required
measurements A through Q in the above drawing. And if you have a radius guage 
that would really be great.

As usual, thanks for any help or advice.

Steve.

Re: ID some core memory

[william degnan via cctalk]

>
>
> >
> >> Bill said
> >>> Just curious...can anyone id the system that used these two types of
> core
> >>> memory?  I am thinking the first is a hand-made custom core, but the
> 2nd
> >> is
> >>> definitely from a commercial system.  Looks kind of IBM-ish but it's
> >>> nothing I can ID.  It's not an IBM 1401 I don't think.
> >>> http://vintagecomputer.net/core-memory/
> >>> Thanks
> >>> Bill
> >>
> >> It's not a 1401 core plane. Here are a couple of pictures of what (I am
> >> pretty sure) is a 1401 core plane that I have from my dad:
> >>http://web.aanet.com.au/~malikoff/ibm/IBM_1401_core_memory_
> plane_1.jpg
> >> Close-up. Has a sharp molded corner and the grooves for the wires:
> >>http://web.aanet.com.au/~malikoff/ibm/IBM_1401_core_memory_
> plane_2.jpg
> >>
> >> Refer to PDF page 12 of http://www.bitsavers.org/pdf/
> >> ibm/1401/A24-1403-5_1401_Reference_Apr62.pdf
> >> for another photo of this.
> >>
> >> Steve.
> >>
> >>
>


I think given the IBM-esque printed markings all types of IBM core should
be ruled out first.  For example the IBM 1620.  But now you can see why I
am asking, what I have does not quite fit.

On the wirewrap side there are four numbered grids on 4 physical plates,
wired together.The ...'s represent "the continuation of wirewrap rows"
1,2,3,4,5,...33 etc.

1  [wirewrap] ---133 [wirewrap]  67 1
   ..
33 165   99 32
   33


34
34 [wirewrap] ---   166  [wirewrap]  100  35
.. ...  ... ...
... 66
66 198132

Re: QSIC update and request

[David Bridgham via cctalk]

On 1/2/18 15:38, Toby Thain via cctalk wrote:

> Err.. could be my mistake... I meant wherever you posted your last
> technical note about QBus quirks. (I didn't look up the reference)

Oh, that paper I wrote about how bus arbitration works on the Unibus and
QBUS.  I'd thought of it as just a way of passing on information I'd
learned to the community about something I thought was interesting but
you're right, it also serves to document some of the internals of the
QSIC since that's where I took it from.

Re: Help diagnosing boot issue SWTPC 6800

[Nick Allen via cctalk]

Well... Finally figured it out!  Found a lose solder blob shorting 2 
pins on one of the motherboard ICs.  That explains why I've been going 
crazy trying to figure out why it's been so random and intermittent.  
Thanks everyone for chiming in, and helping out!



On 1/1/2018 6:12 PM, Nick Allen wrote:
I spoke too soon, I think simply cleaning the contacts rattled a short 
and dumb luck made it boot the first time.  By pressing the 
fatherboard I can see characters corrupt when running a program, guess 
I need to do some more digging to find out exactly where and why this 
is happening.



On 1/1/2018 5:34 PM, Nick Allen wrote:
cleaning the connector pins with a brass brush solved the issue, 
thanks everyone!!



On 1/1/2018 5:03 PM, Nick Allen wrote:
Thanks for the tips everyone!  I can confirm power is GOOD, and the 
problem persists even without the RAM installed (Just CPU and MP-C 
or MP-S board).  I am going to clean the buss connectors and see if 
it helps!


On 1/1/2018 12:32 PM, Nick Allen wrote:
Hey everyone, Happy New Years!  I am thankful for an active 
community that enjoys helping each other learn, and today I am 
coming with an ask for help.


I have a SWTPC 6800 and ADM3A terminal, I can get it to boot, and 
when it boots it will continue to boot for several hours. But 
getting it to successfully boot takes upwards of 100 power OFF and 
ON cycles.  The other 99 times, I get a continuous stream of random 
ASCII characters (see video link below). It's my first time seeing 
this type of issue that happens intermittently, and wondering if 
anyone has any insights in what might be causing this.  I suspect 
its a faulty IC on the Processor board that resets or controls the 
OS reset, will need to deep dive and diagnose, but thought I would 
ask for some direction first.


https://www.youtube.com/watch?v=Ci4vhPn-3PE

Thanks in advance!

-Nick

Re: Vaxstation 4000 m60 and NetBSD

[Maciej W. Rozycki via cctalk]

On Tue, 19 Dec 2017, Charles Dickman via cctalk wrote:

> > Hardware support say no support for LCG Graphics :-(
> 
> There are a few people willing to work on graphics for old
> vaxstations, but there is no documentation.
> 
> If anyone has documentation, the netbsd vax port mailing list would be
> very interested.

 The RAMDAC is standard, so as long as frame buffer memory is mapped into 
the CDAL address space writing a dumb device driver should be pretty 
straightforward with little reverse engineering effort.  And CDAL address 
decoding is I believe documented in the KA46 board specification.

 And all else failing you can always resort to TURBOchannel graphics wired 
via a TURBOchannel adapter.  While not supported by the console monitor, 
it can be handled by the OS just fine, and several TURBOchannel graphics 
drivers are already available for other ports, so it's just a matter of a 
suitable kernel configuration (with minor patching possibly, depending on 
how cleanly written the respective drivers are).

 I was able to get OS console output using at least the HX and one of the 
HX+ options with my m90 and the (still very crippled and long neglected) 
VAX/Linux port several years ago.  The MX, CX and TX options should be 
easily supportable too.  Only accelerators (PixelStamp and PixelVision 
architecture implementations) might cause trouble for one reason or 
another (such as using DMA or requiring a TURBOchannel extender, which are 
scarcer than hen's teeth).

 FWIW,

  Maciej

Re: QSIC update and request

[Toby Thain via cctalk]

On 2018-01-02 3:00 PM, David Bridgham via cctalk wrote:
> On 01/02/2018 02:05 PM, Toby Thain via cctalk wrote:
> 
>>> Oh, I hadn't thought of Toby possibly meaning that.  Yeah, I'm unlikely
>>> to write up much documentation on the internals of the QSIC for people
>>> who want to add other devices.  However, not only will the source be
>> Yes, that's what I meant. In fact I thought that was the point of the
>> device :)
> 
> Well, I guess I thought the point was to produce a working replacement
> for the disk drives that are nearly unobtainable but if it turns out
> that lots of people are seriously interested in developing for the QSIC
> itself, then I'll have to revisit that supposition.  In that case, I'd
> probably write up more internals documentation than I would otherwise.
> 
>> Hope so. And there's always the blog?
> 
> Blog?  Is there a blog about the QSIC that I don't know about?  I'm not
> much of a blogger but if you get me started talking about things that
> interest me I tend to rattle on to excess.
> 
> 

Err.. could be my mistake... I meant wherever you posted your last
technical note about QBus quirks. (I didn't look up the reference)

--Toby

Re: QSIC update and request

[David Bridgham via cctalk]

On 01/02/2018 02:05 PM, Toby Thain via cctalk wrote:

>> Oh, I hadn't thought of Toby possibly meaning that.  Yeah, I'm unlikely
>> to write up much documentation on the internals of the QSIC for people
>> who want to add other devices.  However, not only will the source be
> Yes, that's what I meant. In fact I thought that was the point of the
> device :)

Well, I guess I thought the point was to produce a working replacement
for the disk drives that are nearly unobtainable but if it turns out
that lots of people are seriously interested in developing for the QSIC
itself, then I'll have to revisit that supposition.  In that case, I'd
probably write up more internals documentation than I would otherwise.

> Hope so. And there's always the blog?

Blog?  Is there a blog about the QSIC that I don't know about?  I'm not
much of a blogger but if you get me started talking about things that
interest me I tend to rattle on to excess.

Re: Dumping my first EPROM

[Eric Smith via cctalk]

On Tue, Jan 2, 2018 at 12:13 PM, Brad H via cctalk 
wrote:

> Thanks Paul.  I found an srec2bin converter and ran that.. it created a 1K
> bin file.  I then opened that with a hex editor (slick edit).. but alas, no
> readable strings.
>

Not too surprising, since AFAIK the basic Dynamicro doesn't have any ASCII
I/O. Next step would be to run the binary file through an 8080 (or Z80)
disassembler. I use z80dasm, which is provided as C source code:

https://www.tablix.org/~avian/blog/articles/z80dasm/

but there are many others to choose from.

Without the disassembler, just looking at the object code in hex, you might
see whether there's a pattern in the first 64 bytes of each 8 byte group
containing a few bytes of code then zeros. That's common (but not
universal) in 8080/Z80 code because the reset vector is at address 00, and
the RST instruction vectors are at 00, 08, 10, 18, 20, 28, 30, and 38
hexadecimal.

Re: Asynchronous design - was Re: Computing from 1976

[David Bridgham via cctalk]

On 01/02/2018 02:07 PM, Toby Thain via cctalk wrote:
> On 2018-01-02 1:57 PM, David Bridgham via cctalk wrote:
>> The link didn't work for me but I definitely have that paper -- good
>> stuff indeed.  I should collect my library in one place so I don't lose
>> track of what I have.
>>
> Sorry, this is a better link:
>
> https://dl.acm.org/citation.cfm?id=1283946

That one works, thanks.  It's some pretty interesting work.

RE: Dumping my first EPROM

[Brad H via cctalk]

Thanks Paul.  I found an srec2bin converter and ran that.. it created a 1K bin 
file.  I then opened that with a hex editor (slick edit).. but alas, no 
readable strings.  

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul Berger 
via cctalk
Sent: Tuesday, January 2, 2018 11:05 AM
To: Brad H via cctalk 
Subject: Re: Dumping my first EPROM

I would convert it to a binary image if you could and then look at it with a 
binary editor.  Most binary editors I have seen show the data in hex and also 
have an eye catcher on the right with the ASCII equivalent to the code points.  
 Trying to find strings in S-records would be a bit painful.

Paul.


On 2018-01-02 2:56 PM, Brad H via cctalk wrote:
> Just posting this here in case it reaches eyes not in other forums I'm on.
>
>   
>
> I decided to embark on a project that involves burning a 2708 EPROM.  
> I've never messed with EPROMs before, so I decided to practice.  What 
> I have is a Microworks 2708 'burner' that came with a SWTPC 6800 
> machine I have.  I figured I'd start by learning how to read 2708s.
>
>   
>
> I only had one 2708 lying around to use.  It was installed on a 
> homebrew 'Dynamicro' board (also known as Jon Titus' MMD-1).  It's 
> strange because the MMD-1 doesn't use 2708s.  This board also had a 
> bunch of ICs on it that are not what the MMD-1 design calls for.  So I 
> thought this'd be an interesting EPROM to read anyway, since it might 
> yield a hint as to what the builder was doing with this board, or if 
> they were just using it to store random ICs.
>
>   
>
> Anyway, I fired up the 6800 with the chip in the ZIF socket of the 
> Microworks board and read the contents into memory.  I then punched it 
> back out to my PC terminal as S records.  That's as far as I got.  I'm 
> wondering now how to actually dig into the contents a bit for clues as to 
> what it is.
> I've seen posts in the past from people who were able to find strings, 
> etc that sort of help as clues.  Does anyone know how I'd go further here?
> Really curious what was on this one.
>
>   
>
> Thanks!
>
>   
>
> Brad
>


---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: Asynchronous design - was Re: Computing from 1976

[Toby Thain via cctalk]

On 2018-01-02 1:57 PM, David Bridgham via cctalk wrote:
> The link didn't work for me but I definitely have that paper -- good
> stuff indeed.  I should collect my library in one place so I don't lose
> track of what I have.
> 

Sorry, this is a better link:

https://dl.acm.org/citation.cfm?id=1283946

> 
> On 01/02/2018 01:54 PM, Toby Thain via cctalk wrote:
>> In this vein, Ivan Sutherland's Turing Award lecture, "Micropipelines",
>> might be interesting:
>>
>> http://delivery.acm.org/10.1145/7/63532/a1988-sutherland-1.pdf
>>
>> --Toby
> 
> 

Re: QSIC update and request

[Toby Thain via cctalk]

On 2018-01-02 1:17 PM, David Bridgham via cctalk wrote:
> On 01/02/2018 01:13 PM, Noel Chiappa via cctalk wrote:
> 
> 
>> If you mean the 'software' for additional controllers - that would be a _lot_
>> harder (plus to which it's an entirely different tool-chain, yadda-yadda).
>> 'Use the source, Luke!', I'm probably afraid...
> 
> Oh, I hadn't thought of Toby possibly meaning that.  Yeah, I'm unlikely
> to write up much documentation on the internals of the QSIC for people
> who want to add other devices.  However, not only will the source be

Yes, that's what I meant. In fact I thought that was the point of the
device :)

> available, I'll be around (hopefully) and will be quite willing to
> answer questions.  Shoot, if anyone shows interest I'll probably talk
> their ear off about it.
> 
> 

Hope so. And there's always the blog?

--Toby

Re: Dumping my first EPROM

[Paul Berger via cctalk]

I would convert it to a binary image if you could and then look at it 
with a binary editor.  Most binary editors I have seen show the data in 
hex and also have an eye catcher on the right with the ASCII equivalent 
to the code points.   Trying to find strings in S-records would be a bit 
painful.


Paul.


On 2018-01-02 2:56 PM, Brad H via cctalk wrote:

Just posting this here in case it reaches eyes not in other forums I'm on.

  


I decided to embark on a project that involves burning a 2708 EPROM.  I've
never messed with EPROMs before, so I decided to practice.  What I have is a
Microworks 2708 'burner' that came with a SWTPC 6800 machine I have.  I
figured I'd start by learning how to read 2708s.

  


I only had one 2708 lying around to use.  It was installed on a homebrew
'Dynamicro' board (also known as Jon Titus' MMD-1).  It's strange because
the MMD-1 doesn't use 2708s.  This board also had a bunch of ICs on it that
are not what the MMD-1 design calls for.  So I thought this'd be an
interesting EPROM to read anyway, since it might yield a hint as to what the
builder was doing with this board, or if they were just using it to store
random ICs.

  


Anyway, I fired up the 6800 with the chip in the ZIF socket of the
Microworks board and read the contents into memory.  I then punched it back
out to my PC terminal as S records.  That's as far as I got.  I'm wondering
now how to actually dig into the contents a bit for clues as to what it is.
I've seen posts in the past from people who were able to find strings, etc
that sort of help as clues.  Does anyone know how I'd go further here?
Really curious what was on this one.

  


Thanks!

  


Brad

Re: Asynchronous design - was Re: Computing from 1976

[David Bridgham via cctalk]

The link didn't work for me but I definitely have that paper -- good
stuff indeed.  I should collect my library in one place so I don't lose
track of what I have.


On 01/02/2018 01:54 PM, Toby Thain via cctalk wrote:
> In this vein, Ivan Sutherland's Turing Award lecture, "Micropipelines",
> might be interesting:
>
> http://delivery.acm.org/10.1145/7/63532/a1988-sutherland-1.pdf
>
> --Toby

Dumping my first EPROM

[Brad H via cctalk]

Just posting this here in case it reaches eyes not in other forums I'm on.

 

I decided to embark on a project that involves burning a 2708 EPROM.  I've
never messed with EPROMs before, so I decided to practice.  What I have is a
Microworks 2708 'burner' that came with a SWTPC 6800 machine I have.  I
figured I'd start by learning how to read 2708s.

 

I only had one 2708 lying around to use.  It was installed on a homebrew
'Dynamicro' board (also known as Jon Titus' MMD-1).  It's strange because
the MMD-1 doesn't use 2708s.  This board also had a bunch of ICs on it that
are not what the MMD-1 design calls for.  So I thought this'd be an
interesting EPROM to read anyway, since it might yield a hint as to what the
builder was doing with this board, or if they were just using it to store
random ICs.

 

Anyway, I fired up the 6800 with the chip in the ZIF socket of the
Microworks board and read the contents into memory.  I then punched it back
out to my PC terminal as S records.  That's as far as I got.  I'm wondering
now how to actually dig into the contents a bit for clues as to what it is.
I've seen posts in the past from people who were able to find strings, etc
that sort of help as clues.  Does anyone know how I'd go further here?
Really curious what was on this one.

 

Thanks!

 

Brad

Asynchronous design - was Re: Computing from 1976

[Toby Thain via cctalk]

On 2018-01-02 1:22 PM, David Bridgham via cctalk wrote:
> On 01/01/2018 08:06 PM, Paul Koning wrote:
> 
>> Neat.  I found this 2011 paper that's interesting: 
>> http://www.cs.columbia.edu/~nowick/nowick-singh-ieee-dt-11-published.pdf
> 
> Thanks for this paper, Paul.  I'm quite interested in the idea of
> asynchronous circuit design and I hadn't come across those dynamic
> pipeline designs before.
> 
> 

In this vein, Ivan Sutherland's Turing Award lecture, "Micropipelines",
might be interesting:

http://delivery.acm.org/10.1145/7/63532/a1988-sutherland-1.pdf

--Toby

Re: Computing from 1976

[David Bridgham via cctalk]

On 01/01/2018 08:06 PM, Paul Koning wrote:

> Neat.  I found this 2011 paper that's interesting: 
> http://www.cs.columbia.edu/~nowick/nowick-singh-ieee-dt-11-published.pdf

Thanks for this paper, Paul.  I'm quite interested in the idea of
asynchronous circuit design and I hadn't come across those dynamic
pipeline designs before.

RE: ZX Spectrum Z80 Keeps Resetting

[Rob Jarratt via cctalk]

> -Original Message-
> From: Thorhallur Ragnarsson [mailto:th...@ismennt.is]
> Sent: 02 January 2018 16:59
> To: r...@jarratt.me.uk; Rob Jarratt ; General
> Discussion: On-Topic and Off-Topic Posts 
> Subject: Re: ZX Spectrum Z80 Keeps Resetting
> 
> Hello Rob.
> 
> The power supply voltage might be a bit too high.
> 


Actually I tested that voltage with the PSU not under any load. I just tested 
it connected to the machine and the voltage is 10.15V. Still a bit more than 9V 
though. I'll give it a go with my bench PSU a bit later and see if it works any 
better at 9V.



> Early Spectrums expected a "9V" DC power supply.
> The DC/DC converter that makes +12V, +12VA, -5V and -12V(AC) in some early
> versions (up to Issue 3, IIRC) stops working if the input voltage is too high.
> 
> Happened frequently around midnight here in Iceland when one had typed in
> (but not saved) a long program, because normal people then turned off their
> lights, and the mains voltage went a bit up :)
> 
> Best regards
> 
> Thor.
> 
> 
> - Original Message -
> From: "Rob Jarratt via cctalk" 
> To: "General Discussion: On-Topic and Off-Topic Posts"
> 
> Sent: Monday, January 1, 2018 11:46:13 AM
> Subject: RE: ZX Spectrum Z80 Keeps Resetting
> 
> Replying to my own mail to consolidate my answers to the two very kind
> responses I got.
> 
> In answer to Adrian: Regarding the PSU, I actually have two Spectrums, the
> same PSU seems to power the other one OK. I quickly checked it and it is
> outputting 13.4V and there is no ripple to speak of. So I think the PSU is OK.
> 
> In answer to Jon: I did look at the power rails. The output from the 7805 
> looks
> absolutely fine and the inputs to some of the ICs looks fine. However the Vcc
> input to the Z80 did look a bit noisy, I found there are quite a few spikes, 
> their
> amplitude appears to be 600mV. I temporarily added a 3.5uF capacitor I
> happened to have lying around, this reduced the amplitude of the spikes to
> about 200mV, but didn't affect the behaviour. I am not sure if these spikes
> could cause the reset behaviour though. I suppose the spikes could mean either
> there is a faulty IC (finding that won't be easy), or there is a bad capacitor
> somewhere. I did replace most of the electrolytic ones, but not all of them, 
> so
> that is probably a good line of inquiry.
> 
> I don't think it will be a bad memory location/region in the ROM though
> because a lot of the resets occur in a loop, so it can read the locations, 
> although
> I suppose it is possible that the logic levels on the address/data paths 
> could be
> marginal and occasionally resulting in bad data. My next step was going to be
> to discover how to get my logic analyser to capture the addresses *and* the
> resulting data, but I think I will double check the capacitors first.
> 
> Happy New Year!
> 
> Rob

Re: QSIC update and request

[David Bridgham via cctalk]

On 01/02/2018 01:13 PM, Noel Chiappa via cctalk wrote:


> If you mean the 'software' for additional controllers - that would be a _lot_
> harder (plus to which it's an entirely different tool-chain, yadda-yadda).
> 'Use the source, Luke!', I'm probably afraid...

Oh, I hadn't thought of Toby possibly meaning that.  Yeah, I'm unlikely
to write up much documentation on the internals of the QSIC for people
who want to add other devices.  However, not only will the source be
available, I'll be around (hopefully) and will be quite willing to
answer questions.  Shoot, if anyone shows interest I'll probably talk
their ear off about it.

Re: QSIC update and request

[Noel Chiappa via cctalk]

> From: Toby Thain

> If the documentation is good enough, people in the community will be
> able to provide the software.

You mean, host drivers?

Yeah, that documentation will be pretty trivial: 'there's this extra
register, just like the one in the RLV12; the top 6 bits of the DMA memory
address go in there - the bottom two bits are mirrored into the two extended
memory bits in the CSR'. For the 'extended' RP11, not much more than that.

If you mean the 'software' for additional controllers - that would be a _lot_
harder (plus to which it's an entirely different tool-chain, yadda-yadda).
'Use the source, Luke!', I'm probably afraid...

Noel

Re: QSIC update and request

[David Bridgham via cctalk]

On 01/02/2018 12:45 PM, Toby Thain via cctalk wrote:

> If the documentation is good enough, people in the community will be
> able to provide the software.

The quick answer is that it's pretty simple.  We take the
cylinder/head/sector addresses and consider them a Linear Block
Address.  Then we look around the device registers and pick up a few
more bits that were unused in the RP11 and we end up with a 28-bit
Linear Block Address which works out to a ridiculously huge disk for any
PDP-11 ever conceived.  But yeah, we'll document it.

There will also be an entirely new programming interface into the QSIC
itself, mainly having to do with configuration (like whether or not the
RP11 implementation is stock or extended and how portions of the SD
cards are mapped to various disk packs mounted on the emulated disk
drives).  I intend to write that up too so that people are able to write
programs for their favorite OS that drive the device however they wish. 
I may joke about pointing people to the source to figure out how it
works (it was hard to write, it should be hard to read) but I actually
quite like well-done documentation and will endeavor to produce some.

Re: QSIC update and request

[Toby Thain via cctalk]

On 2018-01-02 9:01 AM, Noel Chiappa via cctalk wrote:
> > From: Mark J. Blair
> 
> > I wonder if it might also be useful in any of the QBUS MicroVAXen?
> 
> Hardwarewise, it should be fine. Softwarewise... well...
> ...
> Anyway, you can see where this is going. For people who can tweak their
> drivers, no biggie. The changes aren't major - a line or two. For people who
> want to run stock software...

If the documentation is good enough, people in the community will be
able to provide the software.

> 
> ...
> Getting around this is all, of course, a SMOP (Small Matter of Programming),
> since a new FPGA load, with support for more emulations, can be installed on
> an existing QSIC at any time.

It seems that you aimed at producing a "platform" all along, so that's
just a natural effect.

--T

> 
> Now, whether Dave would be interested in supporting later devices, or whether
> someone else could be convinced to emulate something more modern ... who 
> knows?
> 
>   Noel
> 

Re: ZX Spectrum Z80 Keeps Resetting

[Thorhallur Ragnarsson via cctalk]

Hello Rob.

The power supply voltage might be a bit too high.

Early Spectrums expected a "9V" DC power supply. 
The DC/DC converter that makes +12V, +12VA, -5V and -12V(AC) in some early 
versions (up to Issue 3, IIRC) stops working if the input voltage is too high.  

Happened frequently around midnight here in Iceland
when one had typed in (but not saved) a long program,
because normal people then turned off their lights,
and the mains voltage went a bit up :)

Best regards

Thor.


- Original Message -
From: "Rob Jarratt via cctalk" 
To: "General Discussion: On-Topic and Off-Topic Posts" 
Sent: Monday, January 1, 2018 11:46:13 AM
Subject: RE: ZX Spectrum Z80 Keeps Resetting

Replying to my own mail to consolidate my answers to the two very kind
responses I got.

In answer to Adrian: Regarding the PSU, I actually have two Spectrums, the
same PSU seems to power the other one OK. I quickly checked it and it is
outputting 13.4V and there is no ripple to speak of. So I think the PSU is
OK.

In answer to Jon: I did look at the power rails. The output from the 7805
looks absolutely fine and the inputs to some of the ICs looks fine. However
the Vcc input to the Z80 did look a bit noisy, I found there are quite a few
spikes, their amplitude appears to be 600mV. I temporarily added a 3.5uF
capacitor I happened to have lying around, this reduced the amplitude of the
spikes to about 200mV, but didn't affect the behaviour. I am not sure if
these spikes could cause the reset behaviour though. I suppose the spikes
could mean either there is a faulty IC (finding that won't be easy), or
there is a bad capacitor somewhere. I did replace most of the electrolytic
ones, but not all of them, so that is probably a good line of inquiry.

I don't think it will be a bad memory location/region in the ROM though
because a lot of the resets occur in a loop, so it can read the locations,
although I suppose it is possible that the logic levels on the address/data
paths could be marginal and occasionally resulting in bad data. My next step
was going to be to discover how to get my logic analyser to capture the
addresses *and* the resulting data, but I think I will double check the
capacitors first.

Happy New Year!

Rob

Re: Boot RXS

[JCWELCH via cctalk]

I am not sure how RSX boots.  Does the message give any indication where in the 
boot process things go wrong?  

I imagine that the boot process loads one part at a time with each part being 
something I would think of as a driver.  So I was wondering if there would be a 
way to look at the boot blocks and say this starts with  so it is for 
device , then the next thing to load is  and that is a  and so 
on until it finally turns execution over to $startup (or whatever the 
equivalent of autoexec.bat from DOS is). That sort of thing is what I meant by 
mounting and examining the disk.

On the other hand might it be possible boot from another installation, attach 
and mount this pack, replace the boot blocks and then boot this system?  I do 
have a six volume set of SYSGEN. I suppose I could make a new one.

Sent from my iPhone

On Jan 2, 2018, at 8:38 AM, Noel Chiappa  wrote:

>> From: John Welch
> 
 SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE WHICH DOES NOT RESPOND.
> 
>> I can boot RSX from a different device (or RT-11, or unix maybe) and
>> then mount this RL02 pack and go exploring through its contents. Is
>> there a possibility that I may find what is missing that way?
> 
> Sorry, I'm confused by this? The message (above) seems to indicate there's
> _hardware_ missing. How is looking through the disk contents going to help
> with that?
> 
> Or is your point that you might be able to find a version of the system which
> does not use that hardware? Perhaps; there's no way to know without looking.
> 
> Noel

Re: Boot RXS

[Jon Elson via cctalk]

On 01/01/2018 10:30 PM, jim stephens via cctalk wrote:



On 1/1/2018 10:35 AM, Noel Chiappa via cctalk wrote:

 > From: John Welch

 > SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE 
WHICH DOES NOT RESPOND.

 > HALTED.
 > Does anyone have any hints on how I can guess what 
I need to add?


Well, Able made a thing called an 'Able ENABLE' which 
allowed use of more
than 256KB of physical memory on any UNIBUS -11 with 
memory mapping hardware
which wasn't an -11/70-44-24. That's probably what it's 
talking about.
I had a meeting with Ken Omohundro on 12/7 and will be 
having dinner with him again soon.  I'll ask him about 
it.  I know he doesn't have any records left, but I could 
take him your notes and see what he recalls.  Also I can 
perhaps get engineer names and try to track them down.


I hope to get a biography and history of his companies 
including Able, and figure somewhere to get it stored.


Hey, this has to be a guy I met at Washington University 
(St. Louis, MO.) in about 1971 or so.


Jon

repairing a dead PDP-11/35

[Henk Gooijen via cctalk]

Best wishes for 2018!
I have been busy trying to repair my dead 11/35.
The system was working, but there was one screw loose that mounts the
system units in the BA11 box ... that screw created a short circuit :-(
After powering the 11/35, ENA/HALT on HALT, and toggling the LOAD ADRS
switch, all DATA lamps go on, and after that the machine is totally
non-responsive.

I installed the KM11 replica from Guy Sotomayor (at last, after 7 years,
I have soldered one of the kits that I had since 2011-2012!). With the
KM11, I can step the microcode right from power up.   When I toggle
LOAD ADRS I see that the SWITCH signal (via the 7474 flipflop) is set,
but when the microcode checks *which* toggle was activated it decides
that none was activated. I measured the signals that play a role here,
and all looks fine.

Now, what gets me puzzled.
If I toggle the LOAD ADRS switch *and hold it pressed down*, then, when
I step the microcode, the branch that handles the LOAD ADRS switch
actually does get executed, and the ADDRESS lamps on the console show
the switch register settings.

Anybody for clues how to proceed?

If you are interested, I made a write up of my testing in (way) more detail:
www.pdp-11.nl/pdp11-35/repair/repair35page.html

Thanks for any advice,
Henk

Semi OT: rocky 518HV

[william degnan via cctalk]

Anyone have one of these single board embedded computers in use?  I have
one that is unresponsive and I believe I need to replace the Dallas battery
chip, similar to other computers like the SunSparc 10 that does nothing
without a working NVRAM battery chip installed.

Any opinions/experience with this card out there?  I have already ordered a
new battery but while I wait I'd like to throw this one out there. Its from
the later 90's not yet "vintage" so that's why the header semi OT.

http://www.voxtechnologies.com/SBCs/pdf/icp/rocky-518hv-ver4-0.pdf

Bill

Re: Boot RXS

[John Welch via cctalk]

I can boot RSX from a different device (or RT-11, or unix maybe) and 
then mount this RL02 pack and go exploring through its contents.  Is 
there a possibility that I may find what is missing that way?


On 1/1/2018 12:35 PM, Noel Chiappa wrote:

 > From: John Welch1

 > SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE WHICH DOES NOT RESPOND.
 > HALTED.
 > Does anyone have any hints on how I can guess what I need to add?

Well, Able made a thing called an 'Able ENABLE' which allowed use of more
than 256KB of physical memory on any UNIBUS -11 with memory mapping hardware
which wasn't an -11/70-44-24. That's probably what it's talking about.

We had one on our -11/45 at MIT, BITD. So I have the programming spec for it,
back-created from the source code for that machine. And Clem Cole was nice
enough to follow up on an old message in an email list archive, and dig up
some documentation and scan it in.

I was planning on doing a page for it on the Computer History wiki, haven't
got a round tuit yet, though.

They are, AFAIK, complete unobtainium in physical form; I've been looking for
years, never seen one.

If someone wanted to upgrade SIMH to support it, we do know enough to do that.

Noel


--
Sincerely,
John Welch
281-353-4706 Home
713-725-7017 Cell
:qw

Re: Boot RXS

[Noel Chiappa via cctalk]

> From: John Welch

>>> SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE WHICH DOES NOT RESPOND.

> I can boot RSX from a different device (or RT-11, or unix maybe) and
> then mount this RL02 pack and go exploring through its contents. Is
> there a possibility that I may find what is missing that way?

Sorry, I'm confused by this? The message (above) seems to indicate there's
_hardware_ missing. How is looking through the disk contents going to help
with that?

Or is your point that you might be able to find a version of the system which
does not use that hardware? Perhaps; there's no way to know without looking.

 Noel

Re: Boot RXS

[Noel Chiappa via cctalk]

> From: Jim Stephens

> I had a meeting with Ken Omohundro on 12/7 and will be having dinner
> with him again soon. I'll ask him about it. I know he doesn't have any
> records left, but I could take him your notes and see what he recalls.

Thanks very much for that offer; we do think we know more or less how it
works (software-wise we always knew, since I wrote the code for it on the MIT
system, and that, and some other code to run it, still survive; the hardware
details had faded from my memory, but the documentation that Clem Cole found
cleared the high-level details of that up, mostly); however, there are two
areas in which he might be able to help.

The first is some very low-level details of how it worked, in terms of the
UNIBUS interaction; we can surmise, from the way it's installed, how it more
or less has to work (details below), but it would be nice to have it
confirmed. The second is some details of how some of the optional stuff for
using existing memory, non-DMA devices, etc worked. (I honestly forget the
details of what I couldn't work out there; I'll have to go study it again.)


The first is that unlike my initial recollections, both the CPU and DMA
devices are on a single UNIBUS segment which feeds into the ENABLE. There are
two different 18->22 maps in the ENABLE, one for CPU cycles, one for DMA (the
latter perfectly emulates the UNIBUS map on the -11/70 and /44). So, more or
less by definition, it has to be able to distinguish CPU bus cycles from DMA
device bus cycles on the incoming UNIBUS segment.

But how, exactly? I can _theorize_ how it did it, but this is a topic not
covered in the still-extant documentation. I _surmise_ that it was something
like it watches NPR/SACK for a DMA cycle (it won't see the NPG, of course),
then waits for BBSY to cycle, at which point it knows it's a DMA cycle; if
not, the current cycle must be from the CPU. He may or may not remember the
details, but if he can, that would be great.

(For software emulation, we don't need to know this, but it would be good,
for completeness' sake, to know. Also, I have a fantasy that the UNIBUS
version of the QSIC will also include ENABLE-type functionality, and although
we could probably work it out on our own, it would be good to have the
benefit of anything he can recall - any not-so-obvious gotcha's, etc.)

It would also be interesting to know why he just didn't use a 3-bus design:
i) UNIBUS in from the CPU, ii) UNIBUS in from DMA devices, and iii) EUB to
the memory. I suspect that the answer is that they way they did it, they
could use a stock MUD backplane (being used in EUB mode), and only one
over-the-back connector into the ENABLE.


On the second, I'll have to go re-read the documentation, and get back.
(Although now that I think about it, I may have just figured out, not only
the question, but also the answer.)


> I hope to get a biography and history of his companies including Able,
> and figure somewhere to get it stored.

The Computer History wiki would seem an ideal place for this sort of content?
(Depending on how long the bio is; but the company info would _definitely_ be
very much on target for there.)

Noel

Re: FFA: Amstrad Joyce (USA)

[Chuck Guzis via cctalk]

On 01/02/2018 06:06 AM, Liam Proven via cctalk wrote:

> Not a request -- I'm in continental Europe and have 2 PCWs anyway, a
> 9512 & a 9512+. But I'm curious -- which model? The basic 8256?

Yup, that's the one, as sold by Sears in the US.

--Chuck

Re: FFA: Amstrad Joyce (USA)

[Liam Proven via cctalk]

On 1 January 2018 at 20:55, Chuck Guzis via cctalk
 wrote:
> There probably aren't that many 120V versions of the Amstrad Joyce Word
> processor, but I've got one here.   I replaced the 3" CF floppy drive
> with a 720K 3.5" drive and modified some boot disks.
>
> The system now supports 3.5" double-sided media and is fully populated
> with 512K of DRAM and runs CP/M 3.0.
>
> Unit with keyboard only, free to good home; sorry but I don't have the
> printer.
>
> I need to get this thing out of the way; if it goes unclaimed by January
> 15, off it goes to NextStep recycling.

Not a request -- I'm in continental Europe and have 2 PCWs anyway, a
9512 & a 9512+. But I'm curious -- which model? The basic 8256?


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

Re: QSIC update and request

[Noel Chiappa via cctalk]

> From: Mark J. Blair

> I wonder if it might also be useful in any of the QBUS MicroVAXen?

Hardwarewise, it should be fine. Softwarewise... well...


The issue is that we're currently only planning to emulate the RK11 and RP11,
because we're not up for the hassle involved in emulating more recent
controllers. (That's not an issue for the systems we want to run.)

We looked at the RP04, and _full_ emulation even of that one is a significant
amount of work. (I stress the 'full' because a partial, simple emulation
might not be too bad, but since we have no idea what various OS's will expect
to be there, it's not clear how much use such a partial emulation would be.)

However, that presents a problem. There are no 22-bit versions of either (in
fact, there's no QBUS RP11 at all; and the QBUS RK11 is restricted to Q16,
for reasons that surpass me). 22-bit operation is needed to make them really
useable as mass storage under Unix, for swapping (because all file system
access is buffered through low memory, purely file system use would be OK
without Q22 support) - at least on -11's with more than 256KB of memory.
(Probably DEC OS's too, but I know nothing of them.)

So, in addition to the dead-stock emulations of the two, we will also support
slightly 'adjusted' versions of the controllers, to have an 'address
extension' register (in exactly the same way the RLV12 has an extra register
over the RLV11).

(And we're also going to have an adjusted version of the RP11, which extends
the size of the disk, using unused bits/values in the disk address registers,
to allow up to 1TB on an 'RP11-D', as we're calling it. Hey, if you're going
to change the controller _at all_... But I digress.)

Anyway, you can see where this is going. For people who can tweak their
drivers, no biggie. The changes aren't major - a line or two. For people who
want to run stock software...


I don't know enough about how the QBUS VAX systems use their disks. Will uVAX
OS's run with only an RKV11-D for mass storage? Somehow I doubt it..

I assume on the later ones (the ones with the private memory bus so they can
have more than 4MB of memory) there's some sort of QBUS map, to map from the
QBUS' 22-bit address space, to the full memory. But does the hardware and
software expect to use the entire 22-bit address space, or are they prepared
to limit it (e.g. for working with an RKV11-D), or what?

I suppose we could add the RLV12 to the list of things we emulate; that's not
_that_ complicated a controller. The problem is that RL's aren't that big
(10MB), and that gets to be an issue with later OS's. And even then VAX OS's
might not run off an RLV12 - I just don't know.


Getting around this is all, of course, a SMOP (Small Matter of Programming),
since a new FPGA load, with support for more emulations, can be installed on
an existing QSIC at any time.

Now, whether Dave would be interested in supporting later devices, or whether
someone else could be convinced to emulate something more modern ... who knows?

Noel

Re: RepaIr stepper motor of an 8 inch drive ?

[Mattis Lind via cctalk]

2018-01-02 11:07 GMT+01:00 jos via cctalk :

>
> Did anyone ever succeed in repairing a stepper motor
>
> Currently restoring a datapoint floppy drive that has been stored in a
> disastrous environment.
>
> The head stepper has a loose wire, currently I cannot even see how to open
> the stepper motor.
>
> It is a Warner Electric SM-024-0045-AS
>
> Cannot see any marking as to who the druive supplier is, it might have
> been Datapoint themselves.



Can you provide a picture of the drive to see if it possible to identify
it. I have a couple of CDC drives, BR8A5D, which I have little use for.
Single sided:

http://i.imgur.com/eP3m06n.jpg
http://i.imgur.com/EA91ayu.jpg
http://i.imgur.com/cMp76YA.jpg
http://i.imgur.com/pWpmdX6.jpg

/Mattis


>
>
> Jos
>

Re: SOT - Ultimate Classic Computing Geekdom

[Alexandre Souza via cctalk]

Awesome!! :D

Enviado do meu Tele-Movel

On Jan 2, 2018 7:32 AM, "Kevin Parker via cctalk" 
wrote:

>
>
> Hi folks - the family surprised me for Christmas by all contributing to
> some custom plates for my new car.
>
>
>
> This might tell you how well they know me.
>
>
>
> http://koken.advancedimaging.com.au/index.php?/albums/
> 274143f7eae640a16c276e89b953503d/
>
>
>
>
>
>
>
>
>
> Kevin Parker
>
> P: 0418 815 527
>
>
>
>
>
>

Re: RepaIr stepper motor of an 8 inch drive ?

[jim stephens via cctalk]

On 1/2/2018 2:07 AM, jos via cctalk wrote:



Cannot see any marking as to who the druive supplier is, it might have 
been Datapoint themselves.
FWIW, the datapoint systems I've had (no longer) had CDC guts.  At least 
I bought a number of MMD 160 SMD drives and other scrap from a datapoint 
repair operation.


thanks
Jim

RepaIr stepper motor of an 8 inch drive ?

[jos via cctalk]

Did anyone ever succeed in repairing a stepper motor

Currently restoring a datapoint floppy drive that has been stored in a 
disastrous environment.

The head stepper has a loose wire, currently I cannot even see how to open the 
stepper motor.

It is a Warner Electric SM-024-0045-AS

Cannot see any marking as to who the druive supplier is, it might have been 
Datapoint themselves.

Jos

SOT - Ultimate Classic Computing Geekdom

[Kevin Parker via cctalk]

 

Hi folks - the family surprised me for Christmas by all contributing to some 
custom plates for my new car.

 

This might tell you how well they know me.

 

http://koken.advancedimaging.com.au/index.php?/albums/274143f7eae640a16c276e89b953503d/

 

 

 

 

Kevin Parker

P: 0418 815 527

 

 

Foxboro drum indicator panel

[Steve Malikoff via cctalk]

Seeing Noel's blinkenlights project and list of panels, for interest's sake 
here is a picture and
decription of the Foxboro drum indicator panel from one of the hardware manuals.
http://web.aanet.com.au/~malikoff/foxboro/FOXBORO_Drum_indicator_panel_1.jpg
http://web.aanet.com.au/~malikoff/foxboro/FOXBORO_Drum_indicator_panel_2.jpg

There was no trace of any panel nor drum when I recovered the Foxboro 2/10 
(PDP-11/15) but I did
find the print set for the above panel (schematics only, no panel hardware 
details), and a set of
RC11 modules (6 flip chips) wrapped with an error list printout. I'm not even 
sure if there was a
drum fitted, as none of the notes I found for the actual installation mention 
it.
There was no other drive in the rack when I got there, so I'm baffled as to 
what device the cards
went to.

Steve.