RE: Fixing an RK8E ....

2020-06-19 Thread Robert Armstrong via cctech
>Josh Dersch 
>   one half-height (used upside down).

  Thanks, Josh - I hadn’t thought about using an extender card "backwards".  
That's a good idea.  Next question is "how many extender cards do I have?"...  
Better go start digging.

  In the meantime I did some more fooling around with the diagnostic and 
discovered that it's apparently not really a stuck command bit after all.  The 
tests are failing are #30 and #31, "VERIFY THAT RECALIBRATE INHIBITS LOAD 
COMMAND" and "VERIFY THAT RECALIBRATE INHIBITS LOAD DISK ADDRESS".  Sounds like 
a problem with the recalibrate function instead.

Bob




Re: Fixing an RK8E ....

2020-06-19 Thread Guy Sotomayor via cctech
On Fri, 2020-06-19 at 12:24 -0700, Robert Armstrong via cctech wrote:
>   It appears that my RK8E has a problem - it fails the diskless
> control test
> with
> 
>   .R DHRKAE.DG
>   SR= 
> 
>   COMMAND REGISTER ERROR
>   PC:1160 GD: CM:0001 
>   DHRKAE  FAILED   PC:6726  AC:  MQ:  FL:
>   WAITING
> 
> Ok, maybe a bad bit in the command register so I'll check it
> out.  But then
> it dawns on me - how do you work on this thing?  It's three boards
> connected
> with "over the top" connectors - you can't use a module extender on
> it.
> Worse, the M7105 Major Registers board is the middle one of the
> stack!   Is
> there some secret to working on this thing?  Has anybody fixed
> one?  Any
> suggestions?
> 
>   I hadn't thought about it before, but the KK8E CPU would have the
> same
> problem.  Fingers crossed that one never dies...
> 

I seem to recall that there were some "special" (read unobtanium) over
the top connectors that permitted one of the boards in a board set to
be up on an extender.

TTFN - Guy




Re: Fixing an RK8E ....

2020-06-19 Thread Josh Dersch via cctech
On Fri, Jun 19, 2020 at 12:24 PM Robert Armstrong via cctech <
cctech@classiccmp.org> wrote:

>   It appears that my RK8E has a problem - it fails the diskless control
> test
> with
>
> .R DHRKAE.DG
> SR= 
>
> COMMAND REGISTER ERROR
> PC:1160 GD: CM:0001
> DHRKAE  FAILED   PC:6726  AC:  MQ:  FL:
> WAITING
>
> Ok, maybe a bad bit in the command register so I'll check it out.  But then
> it dawns on me - how do you work on this thing?  It's three boards
> connected
> with "over the top" connectors - you can't use a module extender on it.
> Worse, the M7105 Major Registers board is the middle one of the stack!   Is
> there some secret to working on this thing?  Has anybody fixed one?  Any
> suggestions?
>

I did some debugging on mine with two quad-height extenders and one
half-height (used upside down).
In such a way you can raise up two of the boards in back (on the quad
extenders) with the one in front installed normally but with the
half-height extender upside-down and plugged into the top connectors, so
the edge fingers of the extender plug into the top blocks.

Yes, it's ugly, and it only gains you access to half of the board you're
trying to poke at.  Building some sort of ribbon cables to substitute in
for the top blocks/upside-down extender would be more, uh, flexible, but I
was fortunate that what I needed to look at was on the unobscured side.

- Josh


>
>   I hadn't thought about it before, but the KK8E CPU would have the same
> problem.  Fingers crossed that one never dies...
>
> Bob
>
>
>


Fixing an RK8E ....

2020-06-19 Thread Robert Armstrong via cctech
  It appears that my RK8E has a problem - it fails the diskless control test
with

.R DHRKAE.DG
SR= 

COMMAND REGISTER ERROR
PC:1160 GD: CM:0001 
DHRKAE  FAILED   PC:6726  AC:  MQ:  FL:
WAITING

Ok, maybe a bad bit in the command register so I'll check it out.  But then
it dawns on me - how do you work on this thing?  It's three boards connected
with "over the top" connectors - you can't use a module extender on it.
Worse, the M7105 Major Registers board is the middle one of the stack!   Is
there some secret to working on this thing?  Has anybody fixed one?  Any
suggestions?

  I hadn't thought about it before, but the KK8E CPU would have the same
problem.  Fingers crossed that one never dies...

Bob




Re: Future of classiccmp

2020-06-19 Thread Adrian Stoness via cctech
You forgot to mention the freenode irc channel as well

Sent from my iPad

> On Jun 18, 2020, at 12:01 PM, jwest--- via cctech  
> wrote:
> 
> The period of me making decisions about the list is coming to an end, but 
> based on all the posts I just caught up with here's some thoughts:
> 
> I would be predisposed to handing it to someone that intends to continue the 
> mailing list format. We already have a very active discord group (which works 
> fantastic for posting pics with your posts), so I see little reason to move 
> to a web based format for this list. Most of us are here cause we prefer the 
> email format. Those who don't - use the discord server, those who like both - 
> use both 
> 
> Picture attachments have been a shortcoming here, there's times when it would 
> be really nice. There are also situations where its likely to be abused 
> especially in the eyes of those who prefer the email format. I would suggest 
> either allow pic posts but only if 1000% on-topic, and even better yet, only 
> allow pics if the mailing list automatically stores them somewhere and only 
> puts a link to the pic in the email. That way, the email stays text only, and 
> users that want to see the pic can. Another approach is maybe 'if you need to 
> post pics, do it on the discord'. One or the other, but the email list should 
> stay a text email service IMHO.
> 
> I did not like the list splitting (cctalk/cctech) when it was done, and still 
> don't. I have intended to rejoin the lists into one list for the past few 
> years and just never got around to it. I will be asking whoever winds up 
> getting the list to do the following tasks as part of the agreement: 1) 
> Rejoin the lists, 2) completely straighten out the archives. Get all the 
> missing stuff, make it all processed and stored in the same way (downloadable 
> archives or text scannable online), and automated. I am embarrassed by how I 
> have let the archives degenerate, but they are still fix-up-able. Whoever 
> takes on the list needs to be prepared to do this as well.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>