[comp.sys.amiga] Ami crashes, RAD:

me128-aw@kepler.Berkeley.EDU (me128 student) (12/06/88)

Help!  I have been having serious problems!

My Amiga has been crashing CONSTANTLY lately, starting about the time I
got 1.3.  When it does, I will be flipping thru screens and an interlaced
screen will come up non-interlaced (so that I only see the upper half).
Everything is still fine until I try flipping this screen to back, using
either the gadgets or keyboard.  At that point, the machine totally locks
up (keyboard & mouse), responding to nothing non-vulcan.  Even the GOMF
button does nothing.  This has occured with a variety of programs and
situations, but I can always repeat it with the following:

   run Diga!       ; Run Diga.  Prefs are set to an interlaced screen
   MWB -i          ; initialize multiple workbench
   MWB N n         ; Open a non-interlaced workbench
   run Memacs file ; run an editor on a non-interlace WB
   [ flip this screen to back to reveal diga ]
   [ diga screen is non-interlaced ... click...BOOM ]

Please note that I am not always running diga or mwb when this occurs,
this is just one such occurance.  What is causing this!!!?

I am running an interlaced, overscan (671x470) workbench, if this is of any
help.  It seems to me that the delacing forewarns of the crash, so there
ought to be a way to remedy the problem.  I am also using SetAlert in my
startup sequence, an boot up with either KS1.2 or KS1.3 (it has crashed
with both)

2) RAD:
For the life of me, I can't recover with 1.3 and RAD:  EVER!  Is this a
slow ram problem?  I use an 880k RRD.  My system is as follows:

   Amiga 1000 with 512k
   Microbotics 2 Meg Expansion Ram
   Chris Erving's 512k memory Hack
   Microbotic Stardrive SCSI controller w/ 20 meg hard drive
   Interlaced, overscan (671x470) Workbench screen
   Gomf button, video hack, audio hack... (Probably irrelevent, but included
     for sake of completeness.

My first instinct is to question the slow piggybacked ram.  Does Fastmemfirst
recognize non-c00000 slow ram?  Shouldn't the 880k size force RAD: to be in
fast ram? 

3) How can I get 2 recoverable ram disks?  Experimentation shows that 2 RADs
don't get along at all.  Even RAD: and VD0: don't like each other.  BOOM!
My Idea is: I want to run Rocket Ranger entirely from ram.  since RR uses its
own disk-fetching code, it won't work with RAM:.  I found that I can diskcopy
one disk to RAD: to speed it up considerably; but I want NO WAITING, PERIOD!

Thanks
-Vincent H. Lee
  

   

scotth@harlie.SGI.COM (Scott Henry) (12/06/88)

From article <27024@ucbvax.BERKELEY.EDU>, by me128-aw@kepler.Berkeley.EDU (me128 student):
> Help!  I have been having serious problems!
> 
> My Amiga has been crashing CONSTANTLY lately, starting about the time I
> got 1.3.  When it does, I will be flipping thru screens and an interlaced
>[... stuff deleted...] 
> I am running an interlaced, overscan (671x470) workbench, if this is of any
> help.  It seems to me that the delacing forewarns of the crash, so there
> ought to be a way to remedy the problem.  I am also using SetAlert in my
> startup sequence, an boot up with either KS1.2 or KS1.3 (it has crashed
> with both)

I have also had this problem, and a similar hardware configuration, BUT, it
has only happened once to me, Though I don't use Diga! or MWB.

> 2) RAD:
>[... second question deleted as I don't know the answer...] 
> 
> 3) How can I get 2 recoverable ram disks?  Experimentation shows that 2 RADs
> don't get along at all.  Even RAD: and VD0: don't like each other.  BOOM!
> My Idea is: I want to run Rocket Ranger entirely from ram.  since RR uses its
> own disk-fetching code, it won't work with RAM:.  I found that I can diskcopy
> one disk to RAD: to speed it up considerably; but I want NO WAITING, PERIOD!

I have figured out how to make RAD: and VD0: co-exist. It is actually fairly
simple: when you first load up the system from a cold boot, VD0: must be
loaded first, AND it must have stuff in it (MORE THAN one cylinder's worth
of data) BEFORE you mount RAD: for the first time (ie: create it). I copy
a small directory's worth of stuff (~6 files, >= 60k) into VD0:, mount RAD:,
copy stuff into RAD:, delete the stuff I copied into VD0:. This has worked
for me for several weeks (except for run-away programs that have clobbered
either/both of RAD and VD0). BTW, I only use a small (9 cylinder) RAD for
auto-booting my hard-drive (also a StarDrive). I recently saw a posting about
how to make 2 RAD: disks co-exist in memory at the same time, you might look
through recent posting history.

> Thanks
> -Vincent H. Lee

 You're welcome,
   Scott Henry
--
              Scott Henry <scotth@harlie.sgi.com> {or, also on the Internet:}
                          <skywalker@cup.portal.com>
#include <std_disclaimer.h>

gmg@hcx.uucp (Greg M. Garner) (12/06/88)

In article <27024@ucbvax.BERKELEY.EDU>, me128-aw@kepler.Berkeley.EDU (me128 student) writes:
>    Gomf button, video hack, audio hack... (Probably irrelevent, but included
>      for sake of completeness.
> 

   What the heck is the video hack? I have the audio hack and the 512 internal
 hack, but never heard of a video hack! Please enlighten me.....

  Greg Garner
  501-442-4847
                 USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmg

bty00298@uxa.cso.uiuc.edu (12/07/88)

The problem with flipping screens is not a new problem with 1.3.  It has always
been a problem with the OS.  It can easily be replicated by opening two
interlaced screens and one non-interlaced screen.  Your problem will be 
duplicated as the screens are flipped.  (It happens to me often)  I heard
somewhere that this is an inherent bug in Kickstart 1.2/1.3 that setpatch
does not fix.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Brian Yamanaka
a struggling student

sc00250@uxa.cso.uiuc.edu (12/07/88)

I've been using rad: and vd0: in conjunction with each other since early June.
And to tell you the truth, I have not had the problems that others have
described here.  
One of the other responses indicated the need to copy files into vd0:, mount
Rad:, then copy form vd0: to rad:, and finally delete the stuff from vd0:.
Forgive my bluntness, but this is totally convoluted.  There is absolutely 
no reason to do this. 

My system consists of a 512K 1000 (the only real Amiga :), with a single drive 
and a 2 meg ram board from Progressive Peripherals.   I have been copying my
boot-up disk to rad: then just boot off Rad: whenever the need arises.

If you still have problems with Rad: then email me and I'll send you a copy
startup-sequence and mountlist.

Overall, I've been content with rad:, the only gripe I have about it is it
sometimes kills my kickstart!!!!!!!!     Why ???????????   If you have the
answer to this problem then please share the answer with someone who is in
the dark.  

 

cjp@antique.UUCP (Charles Poirier) (12/07/88)

In article <27024@ucbvax.BERKELEY.EDU> me128-aw@kepler.Berkeley.EDU (me128 student) writes:
>Help!  I have been having serious problems!
>
>My Amiga has been crashing CONSTANTLY lately, starting about the time I
>got 1.3.

That is coincidence.

>When it does, I will be flipping thru screens and an interlaced
>screen will come up non-interlaced (so that I only see the upper half).
>Everything is still fine until I try flipping this screen to back, using
>either the gadgets or keyboard.  At that point, the machine totally locks
>up (keyboard & mouse), responding to nothing non-vulcan.  Even the GOMF
>button does nothing.  This has occured with a variety of programs and...

This is a long-standing bug in the system.  The bug causes crashes when
you have more than one Interlaced screen plus a Non-interlaced screen
simultaneously, and try to flip among them.  Occasionally it fails to
crash, but don't bet on it.  It's safe to drag screens down by mousing
the title bar.  Sometimes this lets you get to a place from which you
can kill one or more screens so that remaining screens can be flipped
safely.

So remember - don't use TWO interlace plus a non-interlace and then
screen-flip.

-- 
	Charles Poirier   (decvax,ucbvax,mcnc,attmail)!vax135!cjp

   "Docking complete...       Docking complete...       Docking complete..."

peter@sugar.uu.net (Peter da Silva) (12/07/88)

In article <22935@sgi.SGI.COM>, scotth@harlie.SGI.COM (Scott Henry) writes:
> I have figured out how to make RAD: and VD0: co-exist. It is actually fairly
> simple: when you first load up the system from a cold boot, VD0: must be
> loaded first, AND it must have stuff in it (MORE THAN one cylinder's worth
> of data) BEFORE you mount RAD: for the first time (ie: create it).

This is weird, because I have no problem with:

addmem 200000 600000
mount RAD:
mount vd0:
if not exists RAD:c
	diskcopy df0: rad:
endif
if not exists vd0:c
	run copy <nil: >nil: df1: vd0: all
endif
...

Maybe there's some advantage to non-autoconfig RAM after all?
-- 
		    Peter da Silva  `-_-'  peter@sugar.uu.net
		     Have you hugged  U  your wolf today?

	          Disclaimer: My typos are my own damn busines#!rne

me128-aw@kepler.Berkeley.EDU (me128 student) (12/08/88)

In article <1369@cseg.uucp> gmg@hcx.uucp (Greg M. Garner) writes:
>
>In article <27024@ucbvax.BERKELEY.EDU>, me128-aw@kepler.Berkeley.EDU (me128 student) writes:
>>    Gomf button, video hack, audio hack... (Probably irrelevent, but included
>>      for sake of completeness.
>
>   What the heck is the video hack? I have the audio hack and the 512 internal
> hack, but never heard of a video hack! Please enlighten me.....
>
The "video hack" for A1000s appeared in Amazing Computing Vol2 #7, and involved
changing some resistors to improve the color balance.

By the way, while we're talking about hacking amigas, I have also grounded
my PAL chips, added a filtering capacitor in my starboard, and performed the 
1080 monitor hack to fix the interlacing-offset and audio.  I have also
squished the vertical height and superglued a piece of ferrite to the end
of the horizontal coil in the 1080 so I can see the 671/470 wb screen.  Yes, I
love having a HACK-able computer!

-Vincent H. Lee

me128-aw@kepler.Berkeley.EDU (me128 student) (12/08/88)

In article <2450@antique.UUCP> vax135!cjp (Charles Poirier) writes:
>
>This is a long-standing bug in the system.  The bug causes crashes when
>you have more than one Interlaced screen plus a Non-interlaced screen
>simultaneously, and try to flip among them.  Occasionally it fails to
>crash, but don't bet on it.  It's safe to drag screens down by mousing
>the title bar.  Sometimes this lets you get to a place from which you
>can kill one or more screens so that remaining screens can be flipped
>safely.
>
Thanks for the Help.
A few questions:

I have found that the it will NOT crash if the non-interlaced screen is
opened before the second interlaced screen (wb is the first).  I guess 
this makes sense if the non-interlaced screen is trashing some interlaced
bit somewhere when it's opened.  

1) Once it did this while I was playing a beta-version of a new game.
   The game did non open or flip screens, but was just bringing up a 
   requestor in it's interlaced screen.  When it did, the screen flashed
   to non-interlace (BOOM!).  How could this occur?

2) Why hasn't anybody written a patch to fix this?  It seems to me that
   this SERIOUSLY undermines the multitasking nature of the Amiga.  Shouldn't
   it be possible to write a little program which monitors the screen
   ordering and does some magic which the Guru is thinking of dropping
   by?

3) Could anything make this occur more frequently?  I have had an identical
   system configuration for quite some time now, and have had relatively
   few crashes until recently.  As I recall, I have had interlaced and
   non-interlaced screens together often with no problems in the past.

4) Is the interlacing a function of having separate odd and even source
   bitmaps, or just the way the screen is drawn.  In other words, if I
   use SetLace or something like it on the non-interlaced screen, will that
   prevent a crash?

me128-aw@kepler.Berkeley.EDU (me128 student) (12/09/88)

In article <111400012@uxa.cso.uiuc.edu> sc00250@uxa.cso.uiuc.edu writes:
>
>I've been using rad: and vd0: in conjunction with each other since early June.
>One of the other responses indicated the need to copy files into vd0:, mount
>Rad:, then copy form vd0: to rad:, and finally delete the stuff from vd0:.
>Forgive my bluntness, but this is totally convoluted.  There is absolutely 
>no reason to do this. 
>

 have had problems when i try to diskcopy to rad: with vd0: existing.  If I
do so, then both ramdisks will show the contents I just diskcopied, not just
RAD:.   Sometimes vd0: will also lose its name, and the system will just
crash.  It continues to crash until I turn the machine off and then on again.
I haven't tried it in some time, as I wasted a few hours on it some time
ago.

gmg@hcx.uucp (Greg M. Garner) (12/09/88)

In article <27064@ucbvax.BERKELEY.EDU>, me128-aw@kepler.Berkeley.EDU (me128 student) writes:
> 
> By the way, while we're talking about hacking amigas, I have also grounded
> my PAL chips, added a filtering capacitor in my starboard, and performed the 
> 1080 monitor hack to fix the interlacing-offset and audio.  I have also
> squished the vertical height and superglued a piece of ferrite to the end
> of the horizontal coil in the 1080 so I can see the 671/470 wb screen.  Yes, I
> love having a HACK-able computer!
> 
> -Vincent H. Lee

Hey, is this starboard hack something I need to do to mine? (I can't resist
a good hardware hack).  I am sending off for the A1000 schematics so that 
I can start hacking the expansion bus next. I built a small board with a 
VIA on it to control things (like solid state relay-type things), but 
I did something wrong with the handshaking so I never got it working 
(yet). Soon! If I ever get it to work, I'll post all the particulars
right here for all you other dedicated hardware hackers. 
  By the way, if anyone has an idea on how to make a non-autoconfig board
talk to the amiga (Autoconfig comes later, I hope), let me know the details.
I need to know how to let the amiga know that I have a chip out there, as
bringing the vpa* line low is not enough to do the trick. I suspect that I 
must bring another line low to tell the amiga to stretch the cycle for the
6800 style bus access. Thanks!

 

     Greg Garner
     501-442-4847
                  USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmg
 

me128-aw@kepler.Berkeley.EDU (me128 student) (12/10/88)

In article <1390@cseg.uucp> gmg@hcx.uucp (Greg M. Garner) writes:
>Hey, is this starboard hack something I need to do to mine? (I can't resist
>a good hardware hack).  I am sending off for the A1000 schematics so that 
....

The starboard hack really just involves putting a filter capacitor on one of
the lines on the bus.  I did it some time ago on the advice of a friend.  It
seems that the starsdrive puts too much noise on the power lines that a
certain 020 add-on board won't work.

-Vincent H. Lee

FelineGrace@cup.portal.com (Dana B Bourgeois) (12/10/88)

Peter says he has no problems with his startup sequence:

	example deleted

Peter, perhaps it is the fact that you have several megs of Ram.  I suspect
that some of the crashes I have experienced have been memory related.

Dana

riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (12/12/88)

In article <12413@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
>Peter says he has no problems with his startup sequence:
>
>	example deleted
>
>Peter, perhaps it is the fact that you have several megs of Ram.  I suspect
>that some of the crashes I have experienced have been memory related.

I had problems with rad:, ram: and vd0: co-existing on my 2.5 Meg A1000.
Usually the system would just hang after a write to ram:.  After much
futzing about, I discovered that, at least on my system, these ram-disks
are very sensitive to the order they are mounted in.  If I reference ram:
(i.e., copy something to it, or dir it), then mount rad: and reference it,
and then mount vd0: and reference it, the system seems very nicely stable.
If I vary the order (in particular, if I mount vd0: before rad:), it
usually won't even complete the startup-sequence (it hangs in a setenv,
with env: is assigned to ram:env).  This is a bit of nuisance, but I guess
I'm getting used to it.  I am also totally clueless why it works one way
and not the other.

-Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-Wilson Lab, Cornell U.