Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!usc!samsung!munnari.oz.au!comp.vuw.ac.nz!canterbury.ac.nz!chem194
From: chem194@canterbury.ac.nz (John Davis, programmer at large, chemistry department)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: NTSC/PAL switch safe? One more time
Message-ID: <1990Nov4.161456.9663@canterbury.ac.nz>
Date: 4 Nov 90 03:14:56 GMT
References: <9063@ncar.ucar.edu>
Organization: University of Canterbury
Lines: 77

In article <9063@ncar.ucar.edu>, hull@hao.ucar.edu (Howard Hull) writes:
> Ok, on the one hand I have this first article -
> 
> ref1:D A M A G E S  the chip.
> ref1:
> ref1:E-mail: UUCP: ...uunet!unido!fauern!immd4!mlelstv
> ref1:
> 
> and on the other hand, I have this second article -
> 
> ref2:chem194@canterbury.ac.nz (John Davis, programmer at large, chemisry department) replies:
> ref2:A few people here have done that mod, and it seems to be perfectly ok
> ref2:to toggle the switch and reboot, without powering down.
> ref2:
> ref2:Of course, you can always do the same thing via software - have a look
> ref2:at BootMenu and Kill2090 on abcfd20 ( what! me push my own packages, you
> ref2:bet :-)

> Now then, are these two articles paid political announcements, or what?
> With respect to the second article, I _know_ that the statement
> "Of course, you can always do the same thing via software - have a look
> at BootMenu and Kill2090 on abcfd20 ..."
> needs a block of salt if the Amiga has 1 megabyte of chip ram and a CBM
> A2620 card with 2 megabytes of 32-bit memory, since the software in question
> must reset the protected soft ROM NTSC/PAL flag _after_ warm reboot rather
> than before;

actually, the only requirement for software switching NTSC/PAL is the 1mb
Agnus - there is NO requirement for MMUs or anything else. BootMenu and
Kill2090 use the mechanisms for writing reset survivable programs that have
been in the o/s from the beginning ( this is how rad: works - and a lot of
viruses also ). In fact, if you are using a MMU equipped machine and SetCPU
there is the proviso that you MUST invoke bootmenu before setcpu ( as I need
to get at the _physical_ memory for the systemstack - a bug on my behalf that
I hope to fix in the next version ).

Also the NTSC/PAL register is in NO WAY protected - you can quite happily
toggle it at any time, and the video will toggle correspondingly. This isn't
much use with wb1.3 ( video mode will change but the system copper list won't
reflect it - gives kind of interesting displays ) but WB2.0 uses it to allow
user choice of screen mode via preferences on the fly.

Now, since wb2.0 switches NTSC/PAL on the fly that implies to me that 
toggling the register DOESN'T hurt the chip - certainly I've seen no
evidence to support the assertion that you can hurt the hardware by doing so.
I guess there are some monitors that won't like one of the two video standards,
but my 1084s seems equally happy with either.


> thus do I wonder if what it says about the switch is all of the
> time for some of the Amigas, or some of the time for all of the Amigas...
> Are these two articles refering to the same mod (J102), or is there some
> other mod, and if so, what is the one that won't fry the machine?  Does
> anybody out there know for sure?  Where did the thread about frying the
> machine come from, anyway?
> 						Howard Hull
> 						hull@ncar.ucar.edu

As far as I can tell we're all talking about putting a simple open/closed
switch across j102  - it's the only hardware ntsc/pal toggle point I know of (
documented on the sheet for fitting the 1mb agnus ). Since the hardware seems
explicitly set up to only look at the jumper state on reboot only, I find
it hard to believe toggling the line state is going to do any harm. The
software method _has_ to be safe as CBM themselves do it in wb2.0.

My observations have been that both the hardware and software solution 
work fine and cause no  problems (I'm actually running my machine in NTSC mode
at this very moment ) - maybe someone at CBM can give us the 
definitive answer ...
 
-----------------------------------------------------------
| o  John Davis - CHEM194@canterbury.ac.nz               o |
| o  (Depart)mental Programmer,Chemistry Department      o |
| o  University of Canterbury, Christchurch, New Zealand o | 
| o                                                      o |
| o  co-sysop AmigaINFO BBS,1200/2400 baud CCITT,        o |
| o           24 hours a day, ph NZ +3-3371-531          o |