New error with unix on xxu

[Jay Cotton]

In this case, I am in single user mode and running csh shell

The trap 226 I see lots of.  once this traps the machine is done for.

Any ideas ?

root[5] ls                                                                      
adm/       cstand/    guest/     lib/       news/      spool/                  
bin/       dict/      hosts/     local/                                        
trap type 226                                                                  
pc = 0x1D6 sr = 0x2000 up->u_procp = 0x4C814 pid = -1 exec = ''                
0x2700 0x0 0x80 0x2 0x0 0x0 0x0 0x0                                            
0xCA404 0xCA604 0x0 0x0 0x0 0xE800AC 0xE80FFC 0xE80FE6                          
  preserve/  sys/                                                              
catman/    games/     include/   mail/      pub/       tmp/                     

tnx

jc

[Jay Cotton]

A new piece of information.

I switched to cromix to see if I was getting any system errors.  And sure enough I get  

Unexpected interrupt vector e2H .  Which is 226 decimal.

Still don't know where this interrupt is coming from.  

I have 5 boards in the box.

4 meg static ram

STDC

16FDC

XXU

XMU

I can force this error by saying ls -l 

 system[1] ls -l                                                              

         97 D  1   rewa re-- re-- bin         Jan-19  1990  bin              
          7 D  1   rewa re-- re-- system      Feb-07  2036  boot            
          8 D  1   rewa re-- re-- system      Mar-21  2014  bootlarge        
         18 D  1   rewa re-- re-- bin         Jan-19  1990  cmd              
         18    1   rewa re-- re-- system      Nov-28  1997  cromix.172xx    
Unexpected interrupt vector e2H                                              
u.txt    

I can get the error every time.  So its really repeatable.

I suppose I could pull the XMU to see if its generating an interrupt.

jc

[Mike Stein]

Probably not the answer, but the most common cause is the interrupt daisy chain jumper missing or backwards (STDCs Rev C or earlier are opposite of normal)

--
You received this message because you are subscribed to the Google Groups "Cromemco" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cromemco+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cromemco/a4fe5a86-41a0-4ad9-8426-1d0ba86a8b0bn%40googlegroups.com.

[Jay Cotton]

Pulling the XMU makes no difference (as expected).

Hi Mike:  I have checked and rechecked the interrupt daisy chain.  Including point to point from output to input on the next card at the chip level.

I could still be wrong, but it seems unlikely.   And both STDC's are rev D.

I don't know much about cromix, but is it possible to trap an interrupt sequence and decode where/what device is generating the fault.

At this time I am down to 16FDC or XXU getting a fault.  Oddly the error can be produced at exactly the same location every time.

system[2] ls -l                                                              

         97 D  1   rewa re-- re-- bin         Jan-19  1990  bin              
          7 D  1   rewa re-- re-- system      Feb-07  2036  boot            
          8 D  1   rewa re-- re-- system      Mar-21  2014  bootlarge        
         18 D  1   rewa re-- re-- bin         Jan-19  1990  cmd              

         18    1   rewa re-- re-- system      Nov-28  1997  cromix.172xxu    
Unexpected interrupt vector e2H                                              
.txt                                      

If the error is coming from the 16FDC then ifs the console port.  I don't have a floppy connected at this time.

Is there an alternative console i/o port that I can use?  What about IOP is that an option ?

jc

[Richard Muse]

AFIK the 16FDC isn't functional with an XXU. I believe a 64FDC properly patched or 64FDX is necessary. An octart port can be set up as the console for the XXU. I don't think an IOP/Quadart port is an option.

Richard

To view this discussion visit https://groups.google.com/d/msgid/cromemco/b21aa896-f427-4f5a-bdae-2d783ad57b46n%40googlegroups.com.

[Mike Stein]

I'm sure you're right, but it's confusing, no less so because the diagram in some manuals is actually wrong; the color coding just confused things even more since the older boards didn't have it.

The FDCs, the old STDC and the CTI are different from the rest, with IN on the left and OUT on the right, so it starts from the FDC RIGHT to the first I/O right and then left to right on subsequent boards until the STDC, which should be last in the chain.

I can't help much on the hardware level stuff like finding where the interrupts come from and go, but if by chance it's relevant in the 68000 board family manual P.36 there is a table translating the I/O vectors to what the 680x0 wants to see, assuming the 68020 is the same as the 68000.

Good luck!

To view this discussion visit https://groups.google.com/d/msgid/cromemco/b21aa896-f427-4f5a-bdae-2d783ad57b46n%40googlegroups.com.

[Mike Stein]

Ah yes, I hadn't thought of that; I've never tried an XXU with a 16FDC but I *think* it's worked with a plain 64FDC, (unless it's been upgraded); what is the patch you speak of and is it documented anywhere?

No, I don't think the old IOP will work; I believe it needs an IOPX with twice the memory. I've never tried it but I think a TUART might also work, as well as the Octart of course.

To view this discussion visit https://groups.google.com/d/msgid/cromemco/44c62253-3ef6-49d9-a02d-755fb2321852%40gmail.com.

[Peter Higgins]

The attached notes describes the modifications required to make the 64FDC revC and revD work properly (by adding wait states) with an XPU - presumably the same is required if it is used with an XXU?

[Richard Muse]

Nor have I. I have a 16FDC in the ZPU - System 2 but all the others are 64FDC's. The patch is just related to using the 64FDC with 'X series boards' (Mod-4)  and XPU vs DPU (Mod-8).

I don't see a reference to using a TUART with either V.1 or V.2 Unix. According to the 172 sysdef file, 172 Cromix does support the TUART.

**********

Richard

To view this discussion visit https://groups.google.com/d/msgid/cromemco/CAHHfo1vUcx0ZVVRSXcbKjiUnTTyLrqj1pcRjF4h_OnD6kr%2BeQw%40mail.gmail.com.

[Mike Stein]

There he is! I was hoping you'd join in.

Again, I never thought to look at the mod notices. Do you have any yourself or did you download them from the repo? The reason I'm asking is I want to go through the SUDS and other tech notes to make sure that the various repositories including  mine are all in sync, especially that the repo has everything that's available.

To view this discussion visit https://groups.google.com/d/msgid/cromemco/2ff9de19-0189-449b-94d3-d692beaa0836n%40googlegroups.com.

[Mike Stein]

Ah, sorry; yes, I was thinking of XXU Cromix+.

To view this discussion visit https://groups.google.com/d/msgid/cromemco/85aa31ab-458d-48d4-bc2e-c562f0e21e72%40gmail.com.

[Jay Cotton]

I have reviewed all the UNIX and XXU documentation I can find.  (there's a lot).

My conclusion is, if I want to use a floppy disk then I need a 64fdc to get reliable results.

As it stands now, I plan to avoid the 'fdc' controller.  So maybe I can use a TU-ART or an OCT-ART 

to get a system console and run with a console port an unmodified STDC the XXU/XMU and 4 megs of ram.

Best as I can guess, this will work ... 

we shall see

jc

[Jay Cotton]

Well....

Uh, I tried TU-ART, OCT-ART and even 4FDC  No joy for console mode.

So I plugged in the 16FDC and its just working.  The only slight change

is the STDC is over one bus position from its original location.  

I have cleaned the bus connectors and the board edge.  

Happy mistake....  

JC