Path: utzoo!attcan!uunet!seismo!dimacs.rutgers.edu!rutgers!usc!zaphod.mps.ohio-state.edu!ncar!hao.hao.ucar.edu!hull From: hull@hao.hao.ucar.edu (Howard Hull) Newsgroups: comp.sys.amiga.hardware Subject: Re: Monitors Summary: The A2620 was resetting NTSC on soft reboot Keywords: NEC Multisync II Mitsubishi Diamondscan A2620 A2630 Message-ID: <8903@ncar.ucar.edu> Date: 20 Oct 90 16:24:24 GMT References: <2954@isc-br.ISC-BR.COM> <28760@pasteur.Berkeley.EDU> <8800@ncar.ucar.edu> <1990Oct17.034618.8358@assari.tut.fi> Sender: news@ncar.ucar.edu Organization: High Alititude Observatory/NCAR, Boulder CO Lines: 66 In article <1990Oct17.034618.8358@assari.tut.fi> h112706@assari.tut.fi (Herranen Henrik) writes: > >... Monitors that can handle PAL: > >At least Nec Multisync II (NOT 2A!) and Nec Multisync 3D work just fine... > >-- >Henrik 'Leopold' Herranen Internet: h112706@lehtori.tut.fi Well, I didn't get any critical email with respect to monitors distributed in the USA that won't do PAL, but I did get some information from Steve Hillman that enabled me to figure out the problem with my Mitsubishi Diamondscan - something which turned out instead to be a problem with the A2620 '020 accel card in particular, and my particular memory configuration in general. To begin with, for testing the PAL mode I had captured from the net just two programs for PAL, one called PALboot, and one called PAL. The PALboot program was supposed to set some words in the write protected soft ROM scratchpad so that on the next warm reboot AmigaDOS will signal FANG to go PAL. It was an unfortunate consequence of something in the A2620 boot software, I think, but this setting was being reset to NTSC on every soft reboot. (Just out of curiousity, does anyone know it the A2630 does this too?) Worse yet, trying to boot with the A2620 68000 boot option dismissed the 2meg A2620 32-bit ram and left the machine with 1 Meg of entirely chip ram. All Amigas clear chip ram on reboot - so the flag did not survive that way either. This meant that there was no way to use PALboot on the machine on which I was trying to test the PAL mode. The PAL program was designed to change the bit on the fly, but of course it would do this after the Workbench size was already set to NTSC limits. Curiously, Morerows was not effective in extending the video cutoff point beyond 464 lines (this is probably an NTSC copperlist cutoff limit), though it was possible to slide windows some distance down into the zone below the cutoff part (that's the part at the bottom which was blanked to color 0) when the Morerows program was used to get large amounts of overscan. Having determined this, I decided to install the NTSC pal hardware switch across J102. After opening case, I discovered the same thing about that jumper pad pair that I earlier discovered about the 1 meg FANG pad pair, for my rev level of the A2000 motherboard (4.something), (newer bords are ok) namely that there were no posts, no holes drilled, and, in this case, the pads were under the soldermask. I had to scrape that away, I then had to solder switch wires flat to the pads. The first time I tried it after that, I discovered that either of the switch positions measured a short. An quick look with a magnifying glass revealed that, as in the case of the FANG pads, there was a trace between the jumper pads. So I had to cut that out with an Xacto knife. Thus PAL mode is with the switch open, I discovered, since after putting everything back together for the third time, it finally worked and Morerows allowed the Mitsubishi Diamondscan to show 560 lines with the vertical size turned down all the way and the screen drag bar beginning with the first line. So I guess I'll have to take back half the bad things I ever said about the Mitsubishi Diamondscan, and just have a cow the next time I talk about CBM. And yes, after this, I do believe that the Mitsubishi Diamondscan is the best Amiga monitor. Why? Because it not only syncs to NTSC (allowing one to look at VCR playback), it has a separate BNC input for it, and it does the sync-up without clicking any relays. Additionally, it has the smallest "black border" I've seen on any Multisync when used at scan rates of 31.5KHz and higher. It seems that all of them change the size of the scan as the scan frequency input changes, forcing one to do a lot of VSIZE and HSIZE twiddling when switching among video signals with differing scan rates. (So then, do the clicking relays in the NEC compensate for _that_?) Howard Hull hull@ncar.ucar.edu