Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!sm.unisys.com!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!frocky.dec.com!schabacker
From: schabacker@frocky.dec.com (Tim, posting for C. Balzer)
Newsgroups: comp.sys.amiga.tech
Subject: Need help with AmigaShell & '030
Message-ID: <8811171324.AA07262@decwrl.dec.com>
Date: 17 Nov 88 13:24:12 GMT
Organization: Digital Equipment Corporation
Lines: 77


The following mail is from Ralp Babel, who still hasn't a 
real net connection. Don't respond by email, post!

<CB>

I'm using the CoolCapture to configure the memory on my
Ronin/Hurricane board. This way I can use RAD: even though
the memory doesn't auto-config. Also, the earlier this type
of memory is configured, the more system structures will be
put into it. The reason for not using the KickTags: ExecBase
will be moved to 32-bit-RAM as well during the next reboot.

Everything was working fine - until I installed my 68030.

Installing, that is, didn't make a difference. Only after I
changed my memory configuration software to remap Kickstart
into 32-bit-memory (almost no speed improvement) and turn on
the data cache (big deal!).

Now executing the ALIAS command of the AmigaShell (got lots
of them in S:Shell-Startup) almost everytime crashes any
shell newly created. ALIAS? STATUS says "No command loaded",
so I think it's ALIAS. (I tried lots of shell scripts, btw).
Removing all aliases works ok, so does enclosing the aliases
with DCacheOff and DCacheOn (current "solution").

The crash is a requester with three lines of junk (mostly
chr(255)) and it takes several seconds for it to display the
three text lines (while reading lots of memory regions that
don't exist - thanks to the U-descriptor-bit of the PMMU!)
Selecting RETRY or CANCEL will display the usual "Software
failure - task held". Selecting CANCEL then will usually
result in Guru 4.

I've been doing two full days of testing. All programs seem
to work fine (compilers, tools, editors) - except for the
built-in ALIAS command of the AmigaShell. Doing a checksum
on the resident SegList confirmed that L:Shell-Seg is not
trashed by any other program.

What's going on inside the Shell that might break with the
data cache on. Or is there anything else I might have
forgotten?

Yes, Kickstart is 34.5, Workbench is 34.20.

No, no "real" DMA (GVP-SCSI) going on.

Hurricane Memory is non-DMA anyway.

Write Allocation is set.

The '030 is a 20 MHz version running at the usual ~14 MHz.

CACR: WA=1 DBE=0 FD=0 ED=1 IBE=0 FI=0 EI=1
TT0: E=0 FC_BASE=7 FC_MASK=7 LA_BASE=$FF LA_MASK=$FF CI=1 R/W=1 RWM=1
TT1: E=0 FC_BASE=7 FC_MASK=7 LA_BASE=$FF LA_MASK=$FF CI=1 R/W=1 RWM=1
TC: E=1 SRE=0 FCL=0 PS=15 IS=8 TIA=6 TIB=3 TIC=0 TID=0
CRP: ADDR=$007BFF00 L/U=0 LIMIT=$7FFF DT=2
SRP: ADDR=$9FF85850 L/U=0 LIMIT=$0008 DT=0

The table at $7BFF00 contains 64 entries (early termination)
mapping to their corresponding physical memory regions,
except for the Kickstart area which maps to $7C0000.
Hurricane memory is the only region with CI=0.

So all you Gurus out there: HELP!

Thanks,

!ralph

P.S.: Has the cause for the problems with the Hurricane and
the 8-MI-ASDG-RAM-board been determined? The board passed
the ASDG-RAM-test, but wouldn't work unless I turned off the
instruction cache of the '020. Leo?