finkel@TAURUS.BITNET (02/18/90)
Hello everyone,
This is a program I wrote last night to reboot a PAL machine into
NTSC mode. You must have the new Agnus chip, and Kickstart 1.3 .
The program relies on static location of certain Kickstart 1.3
ROM instructions, so it MUST be modified for Kickstart 1.2 . Are there
any users of the new Agnus chip users with Kickstart 1.2??
The program has been tested on a PAL A500 with a super Agnus chip,
a fully populated A590, Kickstart 1.3 ROM, and a Rev 3 motherboard
hacked to contain the super Agnus chip.
The program should work as is on 2000's as well, but I didn't
test it. Again, it will *not* work with Kickstart 1.2 .
The program can be easily modified to reboot an NTSC machine in PAL
mode, but I remember reading that the american monitors can't work
in PAL mode, while the european monitors can work in both modes.
( This was verified by me ;-) ).
I could modify it to be more user-friendly ( find the appropriate
address in the Kickstart ROM at run time, etc. ), but I was too
lazy to do this ;-) ( actually, I had an exam the next morning so I
didn't have too much time improving it ).
Since our Usenet connection has been down for the last 3 weeks, any
comments should be mailed to me directly, and not posted.
Enjoy!
------------ cut ----------- cut ---------- cut -------------------
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# NTSCBoot.asm
# NTSCBoot.uue
# This archive created: Sun Feb 18 12:42:09 1990
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "extracting 'NTSCBoot.asm'" '(2487 characters)'
if test -f 'NTSCBoot.asm'
then
echo shar: "will not over-write existing file 'NTSCBoot.asm'"
else
sed 's/^X//' << \SHAR_EOF > 'NTSCBoot.asm'
X;
X; NTSCBoot.asm
X;
X; Copyright (C) 1990 By Udi Finkelstein.
X; 17 feb 1990
X;
X; Reboot a SuperAgnus equipped PAL machine into NTSC mode.
X;
X; With thanks to Bart Whitebrook from CBM for his article on the new ECS
X; registers in the 3rd european DevCon notes!
X
X; get into supervisor state, since we can only execute RESET there.
X xref _LVOSuperState
X move.l 4,a6
X jsr _LVOSuperState(a6)
X
X; ************************************
X; Warning!!! a grand hack ahead!!!!!!!
X; Never do this stuff alone at home!!!
X; ************************************
X
X; Now we are in supervisor mode, and can issue a RESET command.
X; Unfortunately, after RESET there is no RAM in the system!
X; We can issue exacly *one* instruction ( 1 word length ) because
X; the instruction was fetched before RESET was executed. This
X; instruction can be a 'jmp (aX)', to somewhere on the ROM, where the
X; program can continue. After searching the Kickstart 1.3 ROM, I found
X; that at address $ff4120 you can find the code:
X
X; [ Notice - for Kickstart 1.3 ***ONLY***!!! Is there anybody out there
X; with a Kickstart 1.2/super Agnus combination? you have a problem! ;-) ]
X
X;00FF4120 2741 0038 move.l d1,$38(a3)
X;00FF4124 4281 clr.l d1
X;00FF4126 4ED6 jmp (a6)
X
X; We can use this code fragment to set the NTSC bit in the super agnus,
X; and then jump to the reset code. The PAL/NTSC bit is contained in
X; address $DFF1DC (BEAMCON0 !).
X;
X; 'move.l d1,$38(a3)' writes a longword, therefor $38(a3) must point to
X; $dff1da because it's a read only location, which we can't harm, and
X; $dff1dc contains the PAL/NTSC bit.
X; $38(a3) == $dff1da --> a3 == $ddf1a2
X; we must reset d1 ofcourse, or set d1 == #$00000020 to set PAL mode.
X;
X; ofcourse we have to set a6 to $00000002 to run the reset code later.
X;
X
XROMADR = ($ff4120-$fc0000)
X
X; ROMADR points to $ff4120 after the ROM appears in address $0000.
X
X lea.l $dff1a2,a3
X move.l #$0,d1
X move.l 2,a6
X cnop 0,4
X lea.l ROMADR,a5
X RESET ;reset the machine...
X jmp (a5) ;execute our code fragment.
X
X; Well, that's it. I tried writing a more portable code by trying to
X; set/reset the OVL bit in $BFE001 instead of 'jmp (aX)' after RESET,
X; but I wasn't able to get it working, so the only way I found to run
X; a code after RESET is to find a ROM fragment that happenes to match
X; my requirement. You don't have to tell me how bad it is. Hopefully,
X; the 1.4 preferences will have a PAL/NTSC software switch ( Will it?!!)
X
X END
SHAR_EOF
if test 2487 -ne "`wc -c < 'NTSCBoot.asm'`"
then
echo shar: "error transmitting 'NTSCBoot.asm'" '(should have been 2487 chara
fi
fi
echo shar: "extracting 'NTSCBoot.uue'" '(133 characters)'
if test -f 'NTSCBoot.uue'
then
echo shar: "will not over-write existing file 'NTSCBoot.uue'"
else
sed 's/^X//' << \SHAR_EOF > 'NTSCBoot.uue'
X
Xbegin 644 NTSCBoot
XM```#\P`````````!```````````````(```#Z0````@L>``$3J[_:D?Y`-_Q0
X7HG(`+'@``DOY``-!($YP3M5.<0```_((_
X``
Xend
Xsize 68
SHAR_EOF
if test 133 -ne "`wc -c < 'NTSCBoot.uue'`"
then
echo shar: "error transmitting 'NTSCBoot.uue'" '(should have been 133 charac
fi
fi
exit 0
# End of shell archivejohnf@sag4.ssl.berkeley.edu (John Flanagan) (02/20/90)
In article <9002181052.AA03247@virgo.tau.ac.il> <finkel%math.tau.ac.il@CUNYVM.CUNY.EDU> writes: >Hello everyone, > >This is a program I wrote last night to reboot a PAL machine into >NTSC mode. You must have the new Agnus chip, and Kickstart 1.3 . >The program relies on static location of certain Kickstart 1.3 >ROM instructions, so it MUST be modified for Kickstart 1.2 . Are there >any users of the new Agnus chip users with Kickstart 1.2?? >[...] >The program can be easily modified to reboot an NTSC machine in PAL >mode, but I remember reading that the american monitors can't work >in PAL mode, while the european monitors can work in both modes. Well, just for completeness, I have NewZapped Udi's NTSCBoot to create PALBoot, which reboots North American Amigas into PAL mode. The American 1084 monitor can handle PAL just fine, apparently, since I'm using it that way right now. This also works fine on LUCAS/FRANCES with the 32-bit Kickstart, as I can attest. The uuencoded binary follows. The source code can be found in Udi's post. I apologize for doing this the ugly way (NewZapping) instead of doing this the proper way (reassembling the source code), but I'm having trouble figuring out Lattice's ASM; I'll have to ask Lattice for some better documentation than comes with their compiler, I guess. Anyway, as Udi warns, you NEED the 1-Meg Agnus and Kickstart 1.3 to use this, and it breaks all the rules. But it works, and is a nifty way to get some extra screen real estate for free! Udi: How about submitting NTSCBoot and PALBoot to Tad Guy? -------------------Cut here-------------------- begin 664 PALBoot M #\P ! ( #Z0 @L> $3J[_:D?Y -_Q 7HG(@+'@ DOY -!($YP3M5.<0 _(( end -------------------Cut here-------------------- John Flanagan Space Sciences Laboratory johnf@soc1.ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 643-6308
hamilton@intersil.uucp (Fred Hamilton) (02/20/90)
In article <1990Feb20.013713.12554@agate.berkeley.edu>, johnf@sag4.ssl.berkeley.edu (John Flanagan) writes: > > Well, just for completeness, I have NewZapped Udi's NTSCBoot to create > PALBoot, which reboots North American Amigas into PAL mode. The American > 1084 monitor can handle PAL just fine, apparently, since I'm using it that > way right now. This also works fine on LUCAS/FRANCES with the 32-bit > Kickstart, as I can attest. So what magic are you using to put the 1 meg Agnus in your LUCAS/FRANCES based 1000 (or is it a 500)? -- Fred Hamilton Any views, comments, or ideas expressed here Harris Semiconductor are entirely my own. Even good ones. Santa Clara, CA
johnf@stew.ssl.berkeley.edu (John Flanagan) (02/21/90)
In article <82.25e0fe73@intersil.uucp> hamilton@intersil.uucp (Fred Hamilton) writes: >In article <1990Feb20.013713.12554@agate.berkeley.edu>, johnf@sag4.ssl.berkeley.edu (John Flanagan) writes: >> >> Well, just for completeness, I have NewZapped Udi's NTSCBoot to create >> PALBoot, which reboots North American Amigas into PAL mode. The American >> 1084 monitor can handle PAL just fine, apparently, since I'm using it that >> way right now. This also works fine on LUCAS/FRANCES with the 32-bit >> Kickstart, as I can attest. > >So what magic are you using to put the 1 meg Agnus in your LUCAS/FRANCES based >1000 (or is it a 500)? > It is a LUCAS/FRANCES-based 500. Sorry, I did not mean to get anybody's hopes up. By the way, I have noticed that my 1084, which often suffers from the interlace fuzzies, seems to actually prefer PAL mode; I have not seen any trace of the fuzzies in PAL mode. Maybe it prefers the slower scan rate. So while the flickering is a bit worse in PAL mode than in NTSC mode, PAL mode does provide a sharper picture and a bigger screen (I'm getting 704x564 pixels with morerows). Of course, with PAL mode and morerows, you could get a 704x282 non-interlaced screen as well, which might be a reasonable compromise for those who just can't stand the flicker. John Flanagan Space Sciences Laboratory johnf@soc1.ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 643-6308
bscott@pikes.Colorado.EDU (Ben M Scott) (02/21/90)
I just wanted to publicly thank you for this; (and the original author, of course!) it's a great service to the Amiga community. It is wonderful to have higher resolution for FREE (every test I can run says that system speed is the same, and there is no serious extra DMA overhead), but I can't figure out how it works on the 1084 without twiddling knobs! It actually seems to be scanning at a different speed, because I have a VCR hooked up through the composite and I often switch between screens, and in PAL mode there is a much bigger glitch than when switching NTSC to NTSC. How can the 1084 scan PAL with a 60 hz power supply? Kramden SI reports the VBI as 50 hz, AND the Power supply frequency as 50 hz too. Another interesting note: ECSTest reports the Agnus is still in NTSC mode. Of course, this was the same program that spelled it "NTCS", so what do you want to believe? Another question: How did you fit a Frances into a 500? I thought the Lucas required extreme enough measures... and is it really as buggy as I hear? I'm so far able to live with the 3 megs my 590 gives me, but more is always better! . <<<<Infinite K>>>>
bdb@cl.cam.ac.uk (Brian Brunswick) (02/21/90)
Hi. This is my first attempt at posting to the net, so apologies if anything goes wrong. I have a PAL 1000, but I have noticed that sometimes after a crash it starts up with only a 200 line workbench. I have never really isolated the cause, but could it be related to what this program is doing? But I hear you say that the program doesn't work with old Agnus. So I don't understand it at all. Oh well.
johnf@stew.ssl.berkeley.edu (John Flanagan) (02/23/90)
In article <1768@gannet.cl.cam.ac.uk> bdb@cl.cam.ac.uk (Brian Brunswick) writes: >I have a PAL 1000, but I have noticed that sometimes after a crash it >starts up with only a 200 line workbench. This is caused by a known bug in the boot code, which has been discussed here some time in the past year. I don't remember the details, but it had something to do with some timing which could occasionally fail. I also don't remember whether there was any fix for it. John Flanagan Space Sciences Laboratory johnf@ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 643-6308
ppessi@niksula.hut.fi (Pekka Pessi) (02/24/90)
In article <3313@pikes.Colorado.EDU> bscott@pikes.Colorado.EDU (Ben M Scott) writes: >much bigger glitch than when switching NTSC to NTSC. How can the 1084 scan >PAL with a 60 hz power supply? Kramden SI reports the VBI as 50 hz, AND >the Power supply frequency as 50 hz too. Another interesting note: ECSTest >reports the Agnus is still in NTSC mode. Of course, this was the same program >that spelled it "NTCS", so what do you want to believe? Story tells that it is cheaper to make monitors (and TeeVees) that have the both scan rates. Anyway, I think it is sufficient that the line frequency is the same 15625 Hz. ECSTest tests the "TEST" signal which is grounded for NTSC machines, it doesn't check for video modes. -- Pekka Pessi ppessi@niksula.hut.fi Puh. (90) 455 4757 JT 11E122, 02150 Espoo