setpatch (os3.9, boingbag2) not resident?
DI Rainer Klier
i have the following problem:
the setpatch of os3.9 (with boingbag 2) seems to patch and map the rom *NOT* in a
reset-proof way. the ram-mapped and patched rom will not survive any reset.
i am using an a4000/060 with a cyberstorm mk3 with 96mb ram.
my a4000 *every time* boots twice!
in first boot it installs the patch, then the patched and mapped rom is
reset-proof, and the machine boots again, using this patched and mapped rom.
but resetting again lets the machine "forget" about this patched and mapped rom,
and it is starting all over again, and resets/boots again, coz it again patches
and mapps the original rom.
is this normal?
i can't imagine that this is a feature, and that it should be this way.
but what did i wrong?
i installed os3.9 and the boingbags absolutely normal.
and i have removed nearly all other patches.
switching the maprom-feature from the cyberstormMK3 on or off doesn't change
anything.
additionally annoing is the fact, that i don't have a reset-proof ram-disk
anymore because of this error, because the machine every time makes a cold-reboot.
does anybody know this behaviour?
what can i do?
thanks in advance for every kind of help.
--
Einen schönen Tag noch....
DI Rainer Klier
Angelo
"DI Rainer Klier" <rainer...@gmx.at> wrote in message
news:ap4obf$k27$1...@newsreader1.netway.at...
> hi,
> i have the following problem:
> the setpatch of os3.9 (with boingbag 2) seems to patch and map the rom
*NOT* in a
> reset-proof way. the ram-mapped and patched rom will not survive any
reset.
> i am using an a4000/060 with a cyberstorm mk3 with 96mb ram.
>
> my a4000 *every time* boots twice!
> in first boot it installs the patch, then the patched and mapped rom is
> reset-proof, and the machine boots again, using this patched and mapped
rom.
> but resetting again lets the machine "forget" about this patched and
mapped rom,
> and it is starting all over again, and resets/boots again, coz it again
patches
> and mapps the original rom.
>
> is this normal?
> i can't imagine that this is a feature, and that it should be this way.
Nothing is wrong and it's not patching twice.
First boot setpatch is called then reset under the new
mapped rom, second boot the rom pointers are going to
the patched kickstart. This is normal. On the second boot
when setpatch is called again it detects the patch has been
done already and it just continues booting.
It's not "forgetting" anything.
Jim
Brian E. Doe
<gkpt9.38016$o.23...@news1.west.cox.net> in comp.sys.amiga.misc:
> Nothing is wrong and it's not patching twice.
> First boot setpatch is called then reset under the new
> mapped rom, second boot the rom pointers are going to
> the patched kickstart. This is normal. On the second boot
> when setpatch is called again it detects the patch has been
> done already and it just continues booting.
>
> It's not "forgetting" anything.
That's not the problem, though, from what I read from the original post. What
I read is that nothing (including RAD:, I presume) is surviving warm-boots.
--
Brian Team *AMIGA* NewsCoaster v1.53
Member "I Am Amiga" Fan Club
http://www.amiga-anywhere.com/shop.php?cat_id=22&prod_id=41
Remove spam trap and add .jp to end of address for e-mail
Angelo
"Brian E. Doe" <bdoe.sp...@msa.attmil.ne> wrote in message
news:9061111184931079.NC...@news.kadena.attmil.ne.jp...
Well he made no mention at all about anything other than the
kickstart but something extra is happening in his system.
I need to see a copy of his startup-sequence and user-startup.
There probably is something in there beyond the 3.9
startup.
Jim
DI Rainer Klier
> On Wed, 23 Oct 2002 04:11:56 GMT, "Angelo" ranted and raved about
> <gkpt9.38016$o.23...@news1.west.cox.net> in comp.sys.amiga.misc:
>
>
>
>
> That's not the problem, though, from what I read from the original post. What
> I read is that nothing (including RAD:, I presume) is surviving warm-boots.
you are right brian.
of course i need 2 reboots when i switch on my machine.
but after this, the new patched kickstart should be resident in ram, and should
survive every further reboot/reset.
but it isn't.
and other things which should be resident like my statram.device recoverable
ramdisk also don't survive any further reboot.
it seems, that nothing can survive a reboot.
and so the machine every time reboots twice.
here ist my startup-sequence and my user-startup:
startup-sequence:
; $VER: Startup-Sequence_HardDrive 45.2 (19.1.2001)
; Startup-Sequence for AmigaOS 3.9
;Set SCSIUpdate 1
;If EXISTS SYS:Prefs/Env-Archive/NOSCSIUPDATE
; Set SCSIUpdate 0
;EndIf
;If $SCSIUpdate EQ 1
failat 21
loadmodule Libs:mathieeesingbas.library Libs:mathffp.library L:Shell-Seg NOREBOOT
SetPatch quiet SKIPROMMODULES shell
;Else
; SetPatch SKIPROMUPDATES "scsi.device" QUIET
;EndIf
;Unset SCSIUpdate
c:CMQ060
C:Version >NIL:
;C:AddBuffers >NIL: DF0: 15
FailAt 21
C:MakeDir RAM:T RAM:Clipboards RAM:ENV RAM:ENV/Sys
C:Copy >NIL: ENVARC: RAM:ENV ALL NOREQ
Resident >NIL: C:Assign PURE
Resident >NIL: C:Execute PURE
resident >nil: c:List pure
resident >nil: c:ls pure
resident >nil: c:avail
resident >nil: c:delete
;resident >nil: c:type
resident >nil: c:info
resident >nil: c:copy
resident >nil: c:lock
Assign >NIL: ENV: RAM:ENV
Assign >NIL: T: RAM:T
Assign >NIL: CLIPS: RAM:Clipboards
Assign >NIL: REXX: S:
Assign >NIL: PRINTERS: DEVS:Printers
Assign >NIL: KEYMAPS: DEVS:Keymaps
Assign >NIL: LOCALE: SYS:Locale
Assign >NIL: LIBS: SYS:Classes ADD
Assign >NIL: HELP: LOCALE:Help
BindDrivers
mapdevice parallel 0 to pit 0; lenkt von der internen parallelen auf die mfc3
C:Mount >NIL: DEVS:DOSDrivers/~(#?.info)
C:LoadMonDrvs
SetEnv Language "english"
SetEnv Workbench $Workbench
SetEnv Kickstart $Kickstart
UnSet Workbench
UnSet Kickstart
c:rtpatch >nil: NOASL OPENSCRPATCH
C:AddDataTypes REFRESH QUIET
Run >NIL: c:VisualPrefs
C:IPrefs
C:ConClip
mount sd0:
if not exists sd0:Disk.info
copy devs:sd0-Disk.info sd0:Disk.info CLONE
endif
Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:Prefs SYS:WBStartup
SYS:Tools SYS:Tools/Commodities
SYS:System/REXXMast >NIL:
;IF EXISTS S:User-Startup
Execute S:User-Startup
;EndIF
;Resident Execute REMOVE
;Resident Assign REMOVE
C:LoadWB -debug
EndCLI >NIL:
user-startup:
;stack 124000
;BEGIN ViNCEd
; Remove the ; default console handler CON:
; Entfernen Sie das ; die Standardkonsole CON: verwenden wollen.
SetVNC Quiet Mount Override as CON:
; Remove the ; gadgets with new functions from ViNCEd that can be set with prefs
tool ViNCEd.
; Entfernen Sie das ; Fähigkeiten von ViNCEd in Texteingabefeldern wollen. Diese
konfigurieren Sie
; auch mit dem Voreinsteller ViNCEd.
StringSnip >NIL: INSTALL
; Remove the ; assigns in pattern matching commands.
; Entfernen Sie das ; Unterstützung der mehrfach Assign in Dateinamensmustern
wünschen.
TrueMultiAssigns
;END ViNCEd
;BEGIN MUI
assign MUI: "sys:MUI"
assign add LIBS: MUI:Libs
assign add LOCALE: MUI:Locale
;version >nil: exec.library 39
;if not warn
; if exists MUI:Docs
; if exists HELP:dummy ; do not remove
; endif ; this entry!
assign HELP: MUI:Docs add
; endif
;endif
;END MUI
;BEGIN GoldED
assign golded: "Work3.9:Programme/Text/Studio"
assign libs: "Work3.9:Programme/Text/Studio/etc/libs" add
assign fonts: "Work3.9:Programme/Text/Studio/etc/fonts" add
;END GoldED
;BEGIN JOYCE
assign ispell: golded:add-ons/joyce/ispell
assign libs: ispell:libs ADD
;END JOYCE
;setenvs
;setenv DOOMHOME=dh1:xfh-data/spiele/dooms
; mehrere Assigns
;Assign C4D: dh1:gfx/Cinema4D
;assign PPaint: DH1:GFX/PPaint/
;Assign HOTHELP: "Work3.1:HotHelp"
;ASSIGN MCPP: Work3.1:MCPP3
;ASSIGN EDWARD: MCPP:BIN
;assign POST: XFH-Data:Tools3/PScript/
;assign PSFONTS: XFH-Data:Tools3/PScript/psfonts/
Assign JPEGTMP: swap3.9:
Assign AWeb-II: idh1:programme/Internet/AWeb-II
assign AWeb3: idh1:programme/Internet/AWeb-II
assign PGP: idh1:programme/internet/lib/PGP
;assign WF: dh1:gfx/wildfire
;BEGIN FinalCalc
;ASSIGN FinalCalc: "idh1:Programme/Office/FinalCalc"
;END FinalCalc
;BEGIN Super-Cut
;ASSIGN scut: idh1:Programme/Video/SuperCut
;END Super-Cut
;BEGIN ArtEffect
;ASSIGN ArtEffect: idh1:Programme/GFX/ArtEffect_V3
;END ArtEffect
;BEGIN MaVi
;ASSIGN MaVi: "idh1:programme/GFX/MaVi"
;ASSIGN Images: MaVi:Images add
;ASSIGN Libs: MaVi:Libs add
;ASSIGN ImageCache: MaVi:Cache add
;END MaVi
;BEGIN ImageFX3
;Assign "ImageFX3:" "idh1:programme/GFX/ImageFX3"
;If NOT EXISTS ENV:ImageFX3
; Makedir ENV:ImageFX3
;EndIf
;SetEnv ImageFX/JPEG_Smoothing ON
;END ImageFX3
;BEGIN Photogenics
;assign photogenics: "idh1:programme/GFX/Photogenics"
;assign PGStemp: swap3.9:
;END Photogenics
;BEGIN Photogenics-HELP
;assign pgscd: photogenics:data
;END Photogenics-HELP
;BEGIN Miami
assign Miami: "sys:system/Miami"
;END Miami
;BEGIN YAM - Amiga mailer © Marcel Beck
C:Assign YAM: "idh1:programme/Internet/YAM"
;END YAM - Amiga mailer © Marcel Beck
;BEGIN YAMandPGP
Assign MAILPACKETS: YAM:MAILPACKETS
Assign Mold: MAILPACKETS:oldmessage
Assign Mnew: MAILPACKETS:newmessage/attachment
;END YAMandPGP
;BEGIN TurboPrint
Assign TurboPrint: "sys:system/TurboPrint"
;END TurboPrint
;assign MasterISO: idh1:Tools2/CDROM-Tools/MasterISO_v2
;Pagestream
;Assign PageStream: iDH1:programme/office/PageStream3/
;Assign PageStream3: PageStream:
;Assign PageStream4: PageStream3:
;Assign SoftLogik: PageStream4:SoftLogik/
;Assign fonts: PageStream4:Fonts/ softlogik:fonts/ add
;Patches
;c:PatchSetFunc >nil:
;run >nil: <nil: c:arq ;wird ersetzt durch das neue mrq
;sys:utilities/mrq/MRQ >nil: Configfile=sys:utilities/MRQ/MRQ.config debug DI FS
IBBT=yes|ok|delete|retry|nochmal|ja IMD=sys:utilities/MRQ/MRQ-images
BC=sys:utilities/MRQ/MRQ-images/MRQwin_Cancel.brush
BN=sys:utilities/MRQ/MRQ-images/MRQwin_No.brush BY=sy
;c:cpuclr >nil: ;was iss besser? Mit oder ohne?
;c:CGWBPPatch
;run >NIL: <nil: c:PatchWBPens ;ist inkompatibel zur v4.0 der patch.library!
;c:FasterForbid ;wird ersetzt durch streamlineOS, welches in user-startup2
gestartet wird!
;c:FastWaitBlit >nil:
;phase5 060er tool
c:SetFastAvec >nil:
;Run <>NIL: c:PrinterCGFXPatch
;c:AllocP >NIL: <NIL:
;run >nil: <nil: setasldim width 362 height 450 override ;wenn nicht, sparts 12 KB!
c:CAPrefs >nil: GADGETS=3D PATTERN=MUI:patterns/marbledark
;commodities
idh0:tools/commodities/PowerSnap >nil: CX_POPUP NO SmartSpace HISTORY 6
;run >nil: <nil: dh0:Tools/Commodities/PatchPointer
;run >nil: <nil: dh0:Tools/Commodities/iconify
;run >nil: <nil: dh0:Tools/Commodities/Dragit
;run >nil: <nil: dh0:tools/commodities/CycleToMenu CX_POPUP=NO CX_PRIORITY=0
MAKEZOOM=NO MINZOOMDURATION=8 MAXZOOMDURATION=16 USESCREENFONT=NO MINFONTSIZE=0
MINITEMS=3 LOOK=GADGET FORCENEWLOOKMENU=YES DOUBLEBORDER=YES INNERBORDER=NO
RECESSCURRENT=YES ;mac
;run >nil: <nil: dh0:Tools/Commodities/DPMS DPMS_MODE=OFF delay=1200 standby
;run >nil: <nil: dh0:Tools/Commodities/CGXDPMS offtime=10 standbytime=0
suspendtime=20 BLANKKEY="lalt control b"
;run >nil: <nil: dh0:Tools/Commodities/VesaDPMS CX_POPUP=NO
;run >nil: <nil: xfh:tools3/alertpatch ; Patcht Gurus, wenn nicht, sparts ca. 60 KB!
;run >nil: <nil: dh0:c/StreamLineOS2 quiet
guipath=sys:tools/commodities/StreamLineOS2
sys:system/rexxmast >NIL:
;BEGIN XpkMasterPrefs
Run >NIL: XpkMasterPrefs
;END XpkMasterPrefs
as you can see, most paches are deactivated with comments.
linebreaks made by my mailer-program of course aren't in the original file.
what did i wrong?
Mike Leavitt
> Brian E. Doe wrote:
> > On Wed, 23 Oct 2002 04:11:56 GMT, "Angelo" ranted and raved about
> > <gkpt9.38016$o.23...@news1.west.cox.net> in comp.sys.amiga.misc:
> >
> > I read is that nothing (including RAD:, I presume) is surviving warm-boots.
>
> you are right brian.
> of course i need 2 reboots when i switch on my machine.
> but after this, the new patched kickstart should be resident in ram, and should
> survive every further reboot/reset.
> but it isn't.
> and other things which should be resident like my statram.device recoverable
> ramdisk also don't survive any further reboot.
> it seems, that nothing can survive a reboot.
> and so the machine every time reboots twice.
>
> here ist my startup-sequence and my user-startup:
> linebreaks made by my mailer-program of course aren't in the original file.
>
> what did i wrong?
All I can say is that you have an awful lot in Startup-Sequence that I
have in User-Startup, why did you put so much there? I try to keep it
down to the original OS 3.9 version, and only put patches there that
won't work in User-Startup.
--
Mike Leavitt ac...@lafn.org
Brian E. Doe
<ap8opv$a34$1...@newsreader1.netway.at> in comp.sys.amiga.misc:
Holy Hannah! You don't believe in using the User-Startup file, do you! =:)
> c:CMQ060
What does this command do? If this is used to initialize your CPU card, you
should probably move it closer to the top, just /before/ your SETPATCH
command. This might help.
Alfred Schwarz
>> c:CMQ060
>
> What does this command do? If this is used to initialize your CPU
> card, you should probably move it closer to the top, just /before/ your
> SETPATCH command. This might help.
This is CopyMemQuick for 68060, patches some mem copy/move functions of the
OS.
Ciao, Alfred
Angelo
> Brian E. Doe wrote:
> > On Wed, 23 Oct 2002 04:11:56 GMT, "Angelo" ranted and raved about
> > <gkpt9.38016$o.23...@news1.west.cox.net> in comp.sys.amiga.misc:
Two items from your startup-sequence that will corrupt the 3.9 patched file
causing constant reboots as setpatch checks again and it's not what it
patched.
You have quite a bit of old hacks from the 3.1 days.
> loadmodule Libs:mathieeesingbas.library Libs:mathffp.library L:Shell-Seg
NOREBOOT
> SetPatch quiet SKIPROMMODULES shell
> c:CMQ060
The first item it appears you are force loading a resident modified math
library I assume one of the so called "faster" math libs. Not needed or
recommended under 3.9
The second is not needed at all for the 060 under 3.9.
3.9 already patches the relevant memcopy commands
040/060 and this will also cause setpatch to think it's
patching is nolonger resident and cause constant reboots.
Comment out those two lines and try it again.
That and you really should move anything non 3.9
to the user-startup unless it is absolutely necessary
for initial boot. Scanning your startup I see quite a bit
of extra non OS 3.9 calls that shouldn't be there.
Jim
DI Rainer Klier
>
> Two items from your startup-sequence that will corrupt the 3.9 patched file
> causing constant reboots as setpatch checks again and it's not what it
> patched.
> You have quite a bit of old hacks from the 3.1 days.
only some of them.
as you can see, most of the hacks are commented out.
>>loadmodule Libs:mathieeesingbas.library Libs:mathffp.library L:Shell-Seg
>
> NOREBOOT
>
>> SetPatch quiet SKIPROMMODULES shell
>>c:CMQ060
>
>
>
> The first item it appears you are force loading a resident modified math
> library I assume one of the so called "faster" math libs. Not needed or
> recommended under 3.9
these math libraries ARE faster and necessary.
these are the newest math libs from mathias henze (cyberdyne systems), and are
newer and faster than os3.9 bb#2 math libs.
and i think the author (mathias henze) also uses os3.9 bb#2, so he whould not
publish his libs, if they wouldn't be better.
> The second is not needed at all for the 060 under 3.9.
> 3.9 already patches the relevant memcopy commands
oh, thanks. i didn't know that.
> 040/060 and this will also cause setpatch to think it's
> patching is nolonger resident and cause constant reboots.
but you are wrong in this case.
i found the trouble-maker:
it was multicx's "advanced resethandler" checkbox.
if enabled, the rom update was not reset-proof.
i don't know anymore, for what the "advanced resethandler" is for....
Thomas Richter
> these math libraries ARE faster and necessary.
No, nothing is "necessary" by giving a few percent off.
> these are the newest math libs from mathias henze (cyberdyne systems), and are
> newer and faster than os3.9 bb#2 math libs.
> and i think the author (mathias henze) also uses os3.9 bb#2, so he whould not
> publish his libs, if they wouldn't be better.
As far as the mathffp library is concerned: This is highly obsolete and newer
software should not use it anyhow. Replacing this makes little - if any -
sense. Besides, replacing the FFP by IEEE introduces a couple of problems as
in how to handle numbers near the edge of precision (i.e. "denormalized"
numbers). While I don't know how or whether these are handled correctly, this
subject opens at least a can of worms.
As far as the IEEE libraries are concerned: The so called "faster" math
routines tend to generate unprecise results and are, from a mathematical point
of view, questionable. I tend to test them with a program that just computed
2^12 on the 3.9 libraries, and on the so called "faster" math routines. Now,
according to the faster routines, 2^12 is not even an integer number. In other
words, the "speed" has its price. This is just one of the problems you run into
when doing numerical mathematics: You have to be *very* careful about what
you're doing. Please leave this to mathematicians. The IEEE routines have
been written for good reason the way they have been written. Just ignoring
the fact and run just for speed might cause more problems in the long run.
Hint: For optimal speed with the Os 3.9 math routines, you'd need to use
a 68060.library that offers the "fpsp.resource". The mmu.library based
68060.library does this for you.
>> The second is not needed at all for the 060 under 3.9.
>> 3.9 already patches the relevant memcopy commands
> oh, thanks. i didn't know that.
No, that's not the case. SetPatch does not install any "improved" memory copy.
However, the CMQ060 patch itself is questionable as well. It uses the
MOVE16 command of the 68060 that enforces a bus cycle that is unsupported by
the Zorro protocol. The result is that it *might* seem to work, and it might
even work with your configuration, but from a technical point of view, it is
unclear whether it can work with all possible expansion boards out there. It
might be even *slower* on some machines than a simple move. This is for example
the case on my board: The CPU->zorro bridge detects the illegal access type
(namely "burst"), has to abort it and has to emulate it by "valid" access types.
All this process takes longer than just performing a valid access in first
place.
So long,
Thomas
Angelo
"Thomas Richter" <th...@cleopatra.math.tu-berlin.de> wrote in message
news:apj07e$b20$2...@mamenchi.zrz.TU-Berlin.DE...
> >> The second is not needed at all for the 060 under 3.9.
> >> 3.9 already patches the relevant memcopy commands
>
> > oh, thanks. i didn't know that.
>
> No, that's not the case. SetPatch does not install any "improved" memory
copy.
What I meant was that setpatch OS3.9 is 060 aware and does not
use 040 specific commands vice the 060 versions in conjunction with the 060
library.
MOVE16 does not "enforce" a bus cycle unsupported by
the Zorro spec. It's not a burst mode, where do you get that from?
Jim
Thomas Richter
Hi,
>> No, that's not the case. SetPatch does not install any "improved" memory
>> copy.
> What I meant was that setpatch OS3.9 is 060 aware and does not
> use 040 specific commands vice the 060 versions in conjunction with the 060
> library.
There are no "040 specific" commands the SetPatch cares about in this sense,
nor is there anything 040/060 specific within exec itself, leave alone
anyting in the range of "CopyMem()" and friends. All it does is that it loads
now the proper cpu support library, i.e. the 68060.library for the 060.
It wasn't clever enough for doing so before and you had to use some strange
constructions as the "dummy" 68040 library.
> MOVE16 does not "enforce" a bus cycle unsupported by
> the Zorro spec. It's not a burst mode, where do you get that from?
MOVE16 runs a burst mode regardless of the caching mode, unlike ordinary MOVE
instructions which only burst on a cache-push if the page is cachable.
Please see the motorola manuals, especially the 68040/68060 UM/AD, available
on the motorola sides.
So long,
Thomas
Angelo
>
> Hi,
>
> >> No, that's not the case. SetPatch does not install any "improved"
memory
> >> copy.
>
> > What I meant was that setpatch OS3.9 is 060 aware and does not
> > use 040 specific commands vice the 060 versions in conjunction with the
060
> > library.
>
> There are no "040 specific" commands the SetPatch cares about in this
sense,
> nor is there anything 040/060 specific within exec itself, leave alone
> anyting in the range of "CopyMem()" and friends. All it does is that it
loads
> now the proper cpu support library, i.e. the 68060.library for the 060.
> It wasn't clever enough for doing so before and you had to use some
strange
> constructions as the "dummy" 68040 library.
Setpatch in OS3.9 also calls handlers for FPU and the newer
scsi.device patch, there are 060/040 specific optimisations/omissions
that are taken into account there depending on the cpu.
You still do have to use a strange contruction. Setpatch only calls the
68040.library still. On 060 systems this is replaced with a dummy loader
that detects which processor is present then loads the appropriate
library. The 060 boards and their loaders existed long before OS3.9
so no effort was made for setpatch to change the lib call as it's already
taken care of.
> > MOVE16 does not "enforce" a bus cycle unsupported by
> > the Zorro spec. It's not a burst mode, where do you get that from?
>
> MOVE16 runs a burst mode regardless of the caching mode, unlike ordinary
MOVE
> instructions which only burst on a cache-push if the page is cachable.
> Please see the motorola manuals, especially the 68040/68060 UM/AD,
available
> on the motorola sides.
>
> So long,
> Thomas
I've read the sheets before and again now, it details a design spec command
for a burst mode however it also allows for inhibiting the burst if your
bus implementation doesn't support it. It's not a forced mode just by
calling
move.
Jim
Thomas Richter
Hi,
> Setpatch in OS3.9 also calls handlers for FPU and the newer
> scsi.device patch,
There are no "handlers for the FPU". These are done in the 68040.library
and the 68060.library. Hey, I *wrote* these. SetPatch attacks some bugs
in the mathieeesingbas library for *some* Os ROMs that install the
library in an "incorrect mode", but that's about it. All the remaining
exception handlers for the FPU are setup by the 68040 resp. 68060.lib.
There are also no "handlers" for the scsi.device, just a resident node that
gets linked into the system as part of the rom-update mechanism and
possibly a couple of patches if you don't install it.
> there are 060/040 specific optimisations/omissions
> that are taken into account there depending on the cpu.
> You still do have to use a strange contruction. Setpatch only calls the
> 68040.library still.
This is just plain wrong. The latest setpatch in BB2 *does* load the
68060.library on a 68060 based machine. That was the result of a long
and anoying discussion I had with Heinz until he finally came up with the
new construction that is available in the BB2 SetPatch.
> On 060 systems this is replaced with a dummy loader
> that detects which processor is present then loads the appropriate
> library. The 060 boards and their loaders existed long before OS3.9
> so no effort was made for setpatch to change the lib call as it's already
> taken care of.
True for pre-3.9 BB2, incorrect now. Hey, I've been involved in this process,
don't tell me, right!
> I've read the sheets before and again now, it details a design spec command
> for a burst mode however it also allows for inhibiting the burst if your
> bus implementation doesn't support it. It's not a forced mode just by
> calling move.
And now, who tells that this "inhibiting" works for all boards? Zorro
IO addresses and specifically chip ram is "cache inhibited" by the MMU
or the TTx registers, hence all accesses going out to chip are uncached
and non-bursted for "regular" accesses. Hence, a board would still work
fine if there is no inhibiting mode since the CPU would never burst on
chip ram anyhow.
Even if it works, who says that aborting the burst doesn't take time? On my
machine, it's getting slower with MOVE16 than with MOVE.
In other words, CMQ060 requires a board that has been well-designed, *and*
that takes advantage of bursting for its own (or possibly) motherboard RAM
that is burst-able. Given the rather low quality of some boards, I have my
doubts if you can safely recommend a tool like this to the average user
owning an average 060 board.
Besides, please show me a single program that takes a serious advantage of
the patches CopyMemQuick(). The potential cost is high compared to what it
does: It's not worth the trouble.
So long,
Thomas
Angelo
>
> Hi,
>
> > Setpatch in OS3.9 also calls handlers for FPU and the newer
> > scsi.device patch,
>
> There are no "handlers for the FPU". These are done in the 68040.library
> and the 68060.library. Hey, I *wrote* these. SetPatch attacks some bugs
> in the mathieeesingbas library for *some* Os ROMs that install the
> library in an "incorrect mode", but that's about it. All the remaining
> exception handlers for the FPU are setup by the 68040 resp. 68060.lib.
> There are also no "handlers" for the scsi.device, just a resident node
that
> gets linked into the system as part of the rom-update mechanism and
> possibly a couple of patches if you don't install it.
What OS roms are installing it in an incorrect mode? You are talking
about the kickstart specificaly right?
Resident node or handler. Potatoes/pototoes in layman speak.
> > there are 060/040 specific optimisations/omissions
> > that are taken into account there depending on the cpu.
> > You still do have to use a strange contruction. Setpatch only calls the
> > 68040.library still.
>
> This is just plain wrong. The latest setpatch in BB2 *does* load the
> 68060.library on a 68060 based machine. That was the result of a long
> and anoying discussion I had with Heinz until he finally came up with the
> new construction that is available in the BB2 SetPatch.
Does it overwrite the existing dummy loader 68040.library from
any cyberstorm install? If so something is broke in the update if
this is what it is supposed to do because no change was made
to my dummy loader 68040.library on my system and should
I revert to an 040 accell in there, setpatch is still calling the
68040.library which is the dummy loader still. Doesn't affect
it at all of course since the dummy loader still grabs the proper
lib anyway but BB2 hasn't changed this and I have no way
of determining if setpatch is grabbing the 060 lib directly
either unless something like snoopdos can run that early
in the startup and provide an output.
> > On 060 systems this is replaced with a dummy loader
> > that detects which processor is present then loads the appropriate
> > library. The 060 boards and their loaders existed long before OS3.9
> > so no effort was made for setpatch to change the lib call as it's
already
> > taken care of.
>
> True for pre-3.9 BB2, incorrect now. Hey, I've been involved in this
process,
> don't tell me, right!
Has there been a falling out then? BB2 is not even "hinted" at on the
www.amiga.com
web pages or in the FAQ, ONLY BB1 and hasn't since the page went up. Why is
that?
>
> > I've read the sheets before and again now, it details a design spec
command
> > for a burst mode however it also allows for inhibiting the burst if your
> > bus implementation doesn't support it. It's not a forced mode just by
> > calling move.
>
> And now, who tells that this "inhibiting" works for all boards? Zorro
> IO addresses and specifically chip ram is "cache inhibited" by the MMU
> or the TTx registers, hence all accesses going out to chip are uncached
> and non-bursted for "regular" accesses. Hence, a board would still work
> fine if there is no inhibiting mode since the CPU would never burst on
> chip ram anyhow.
> Even if it works, who says that aborting the burst doesn't take time? On
my
> machine, it's getting slower with MOVE16 than with MOVE.
>
> In other words, CMQ060 requires a board that has been well-designed, *and*
> that takes advantage of bursting for its own (or possibly) motherboard RAM
> that is burst-able. Given the rather low quality of some boards, I have my
> doubts if you can safely recommend a tool like this to the average user
> owning an average 060 board.
>
> Besides, please show me a single program that takes a serious advantage of
> the patches CopyMemQuick(). The potential cost is high compared to what it
> does: It's not worth the trouble.
>
> So long,
> Thomas
Thomas I see your point and am not arguing that it is a good practice, just
that
it's conventions aren't as draconian as you make them to be. The "average"
68060 board out there by sheer sales is the Cyberstorm hands down and
no one has reported such problems and this is with a plethora of zorro
card combinations in use. The Cyberstorm MK-1 even has the burst
option jumperable by the end user.
Jim
Thomas Richter
Hi Jim,
>> There are no "handlers for the FPU". These are done in the 68040.library
>> and the 68060.library. Hey, I *wrote* these. SetPatch attacks some bugs
>> in the mathieeesingbas library for *some* Os ROMs that install the
>> library in an "incorrect mode", but that's about it. All the remaining
>> exception handlers for the FPU are setup by the 68040 resp. 68060.lib.
>> There are also no "handlers" for the scsi.device, just a resident node
> that
>> gets linked into the system as part of the rom-update mechanism and
>> possibly a couple of patches if you don't install it.
> What OS roms are installing it in an incorrect mode?
This is not a matter of the Os ROM alone. It is also a matter of the firmware
of the 68060 card you're using. Since the Os ROM does not support the 68060,
the firmware has to play certain tricks to boot up correctly. The major
difference between the 68060 and all former processors is the FPU, specifically
the stack frame on an FSAVE that gets used in the exec scheduler. For that
reason, the firmware of most boards disable the 68060 FPU on startup. This
makes the init function of the mathieeesingbas "think" that it is running
on an FPU-less system and installs a "CPU only" version of mathieeesingbas
into the system. This is observed for example on the A2000 ROM (e.g. my
system I have at home). Some 68060.libraries work around the bug, and it
is attacked in the latest SetPatch as well.
> You are talking
> about the kickstart specificaly right?
> Resident node or handler. Potatoes/pototoes in layman speak.
Well, a "handler" is something that resides in L: as L:Port-Handler. (-;
>> This is just plain wrong. The latest setpatch in BB2 *does* load the
>> 68060.library on a 68060 based machine. That was the result of a long
>> and anoying discussion I had with Heinz until he finally came up with the
>> new construction that is available in the BB2 SetPatch.
> Does it overwrite the existing dummy loader 68040.library from
> any cyberstorm install?
No. It just doesn't load it. If it detects the 68060, it loads the
68060.library right away.
> If so something is broke in the update if
> this is what it is supposed to do because no change was made
> to my dummy loader 68040.library on my system and should
> I revert to an 040 accell in there, setpatch is still calling the
> 68040.library which is the dummy loader still.
That's no longer necessary. Get rid of the 68040dummy, rename the "real"
68040.library back into "68040.library" and leave it to setpatch to load
the proper one. All for BB2, of course.
> Doesn't affect it at all of course since the dummy loader still grabs
> the proper
> lib anyway but BB2 hasn't changed this and I have no way
> of determining if setpatch is grabbing the 060 lib directly
> either unless something like snoopdos can run that early
> in the startup and provide an output.
The 68040.library won't load on 68060. At least *my* 68060.library; it would
go guru on an installation error as this one. At *least* you would notice
the problem because the system runs then without a FPU most likely. It is
the matter of the 68060.library to re-enable it and insert the fixed exec
scheduler code - on most 68060 boards.
>> True for pre-3.9 BB2, incorrect now. Hey, I've been involved in this
> process,
>> don't tell me, right!
> Has there been a falling out then? BB2 is not even "hinted" at on the
> www.amiga.com
> web pages or in the FAQ, ONLY BB1 and hasn't since the page went up. Why is
> that?
I don't know. I haven't put up the web space, but you might be able to
get it at the H&P web page.
> Thomas I see your point and am not arguing that it is a good practice, just
> that
> it's conventions aren't as draconian as you make them to be. The "average"
> 68060 board out there by sheer sales is the Cyberstorm hands down and
> no one has reported such problems and this is with a plethora of zorro
> card combinations in use. The Cyberstorm MK-1 even has the burst
> option jumperable by the end user.
"no one has reported problems" is not really a proof. The kind of problems
you're likely to expect are "instability" you cannot easily trace back to
CMQ060 in first place. It would not work only for some programs (namely,
those using the CopyMemQuick()), and in some situations (e.g. a heavely
loaded Zorro Bus). In other words, I do not recommed it because you cannot
really say what could happen, and when it would happen. I do not see much
sense in the program either as I haven't really seen a program that
benefits noticably from it.
So long,
Thomas
Angelo
>
> Hi Jim,
> > Does it overwrite the existing dummy loader 68040.library from
> > any cyberstorm install?
>
> No. It just doesn't load it. If it detects the 68060, it loads the
> 68060.library right away.
>
> > If so something is broke in the update if
> > this is what it is supposed to do because no change was made
> > to my dummy loader 68040.library on my system and should
> > I revert to an 040 accell in there, setpatch is still calling the
> > 68040.library which is the dummy loader still.
>
> That's no longer necessary. Get rid of the 68040dummy, rename the "real"
> 68040.library back into "68040.library" and leave it to setpatch to load
> the proper one. All for BB2, of course.
Done, BB2 installed, dummy 040.lib deleted, 68040new.library renamed
to 68040.library. All is still working fine. ;-)
> >> True for pre-3.9 BB2, incorrect now. Hey, I've been involved in this
> > process,
> >> don't tell me, right!
>
> > Has there been a falling out then? BB2 is not even "hinted" at on the
> > www.amiga.com
> > web pages or in the FAQ, ONLY BB1 and hasn't since the page went up.
Why is
> > that?
>
> I don't know. I haven't put up the web space, but you might be able to
> get it at the H&P web page.
Yup that's where I got it from. Still odd that BB2 has never been mentioned
on www.amiga.com directly or in the OS3.9 FAQ that has updates as recent
as last month.
> > Thomas I see your point and am not arguing that it is a good practice,
just
> > that
> > it's conventions aren't as draconian as you make them to be. The
"average"
> > 68060 board out there by sheer sales is the Cyberstorm hands down and
> > no one has reported such problems and this is with a plethora of zorro
> > card combinations in use. The Cyberstorm MK-1 even has the burst
> > option jumperable by the end user.
>
> "no one has reported problems" is not really a proof. The kind of problems
> you're likely to expect are "instability" you cannot easily trace back to
> CMQ060 in first place. It would not work only for some programs (namely,
> those using the CopyMemQuick()), and in some situations (e.g. a heavely
> loaded Zorro Bus). In other words, I do not recommed it because you cannot
> really say what could happen, and when it would happen. I do not see much
> sense in the program either as I haven't really seen a program that
> benefits noticably from it.
>
> So long,
> Thomas
True, I'm not sure where if anything would benefit from it either, save
for maybe a benchmarking program getting a few more points, but
in the area of critical use where qualitative and quantitative output
is required I agree CMQ060 is not the answer.
Jim